[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
pkg/44953: /usr/pkg/lib in default linker path causes configure errors
>Synopsis: /usr/pkg/lib in default linker path causes configure errors
>Arrival-Date: Wed May 11 09:00:01 +0000 2011
>Originator: Matthias Rampke
>Release: DragonFlyBSD 2.10 and 2.11
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
build mail/alpine on recent DragonFly with tcl installed and the
line removed from Makefile.
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
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.
Main Index |
Thread Index |