On Tue, 21 Feb 2012, Steve Kargl wrote:
On Tue, Feb 21, 2012 at 05:00:53PM -0500, Diane Bruce wrote:
On Tue, Feb 21, 2012 at 10:37:15PM +0100, Dimitry Andric wrote:
On 2012-02-21 20:42, Steve Kargl wrote:
...
Yes, /lib comes before /usr/local/lib/gcc46. I suppose
that this is a heads up for gerald@. lang/gcc is used by
the ports collections to build a large number of other
ports, so others are likely to hit this issue.
Does -rpath not help ?
I already mentioned that I can add '-rpath /usr/local/lib/gcc46'
to my various projects. I can also build with -static to avoid
rtld. One can also use LD_LIBRARY_PATH.
The issue seems to be that lang/gcc will be installed after
system start, and 'ldconfig -m' appends new shared libraries
to the hints file. This means that libraries with the same
name but different locations will be found via the order of the
search path in the hints file, and one gets the wrong library.
That is, with the following
troutmask:root[256] ldconfig -r | grep libgcc_s
29:-lgcc_s.1 => /lib/libgcc_s.so.1
723:-lgcc_s.1 => /usr/local/lib/gcc46/libgcc_s.so.1
29 will be found before 723. While I can work around the
issue, lang/gcc is used by a rather large boatload of ports
during the building process and I suspect that a large
number of FreeBSD users use lang/gcc for their everyday
compiler. The question is how do we, the FreeBSD project,
deal with this issue, so that the general user base does not
get hit with it.
I think there is perhaps a little more to this issue of multiple
(incompatible) copies of a library with the same name being installed,
e.g. libcom_err in /usr/lib/libcom_err.so and
/usr/local/lib/libcom_err.so. An application using the library must
#include <com_err.h> to get the library prototypes, but the preprocessor
puts the standard include search path /usr/include at the end of the
search list, even if it is specified explicitly on the command line,
unless -nostdinc is passed. So this will prefer the header from ports in
the absence of evil trickery.
I was pounding my head against this a couple years ago, so my memory is
not quite fresh, but I think that I could convince the compile-time link
step to use either version of the library with the appropriate ordering of
-L arguments (but I am in trouble if I want libkrb5.so from ports and
libcom_err.so from base!).
In any case, the dynamic linker will search the default search path
*first*, preferring the copy of the library from the base system. After
pounding my head against the issue for a while I concluded that I had no
option other than to use -rpath (but alas I ran out of time for that
particular project and never finished).
It is definitely an ugly situation and I have no good answers. It would
be nice to not have to specify every detail of what should be happening,
though.
There are a few solutions:
1) Set ldconfig_paths in /etc/rc.conf to cause ${PORTSDIR}/lib to
be scanned before /lib and /usr/lib.
2) Use /etc/ld.so.conf to cause ${PORTSDIR}/lib to be scanned
for /lib and /usr/lib.
3) Add a new option to ldconfig to prepend new libraries to
the hints files and fix the ports to use this option instead
of -m.
4) Suggestions from people that are brighter than I.
How would things break if we made everything in the base system specify
-rpath of /lib and /usr/lib as appropriate, and then put the ports
versions first in the default search path?
-Ben Kaduk
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
