pkg/44953: /usr/pkg/lib in default linker path causes configure errors

[matthias.rampke%googlemail.com@localhost]

>Number:         44953
>Category:       pkg
>Synopsis:       /usr/pkg/lib in default linker path causes configure errors
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed May 11 09:00:01 +0000 2011
>Originator:     Matthias Rampke
>Release:        DragonFlyBSD 2.10 and 2.11
>Organization:
>Environment:
>Description:
Since a recent binutils upgrade DragonFly BSD includes /usr/pkg/lib in the 
default library search path. This causes some configure scripts to detect some 
installed libraries as present without them actually being buillink3ed in, see 
e.g. PRs pkg/44944 and pkg/44916. There is some discussion about this on the 
latter, but I open this PR so this can be discussed in general.

Since the headers are being shielded by the build wrappers, the build fails in 
these cases. 


>How-To-Repeat:
build mail/alpine on recent DragonFly with tcl installed and the

CONFIGURE_ARGS+=        --without-tcl

line removed from Makefile.
>Fix:
The question is, if and where this should be fixed. Options I see are:

1) Don't fix.
When problems with individual packages arise, the configure test can be forced, 
either unconditionally (as with pkg/44945) or with an option (as with 
pkg/44916) so the reliability and predictability of these packages actually 
increases.

2) Fix in DragonFly
Remove /usr/pkg/lib from default ld path, problem goes away for now - until 
some other OS decides to include it.

3) Fix in buildlink3
Find a way to reset the ld search path or specifically remove /usr/pkg/lib from 
it. Fixes this hole once and for all, but it's unsure if this is possible for 
any or all of the ld's out there.