[csw-devel] SF.net SVN: gar:[16750] csw/mgar/pkg/gcc4/branches/private-lib/

Peter FELECAN pfelecan at opencsw.org
Sun Jan 15 20:43:01 CET 2012


"Maciej (Matchek) Bliziński" <maciej at opencsw.org> writes:

> 2012/1/12 Peter FELECAN <pfelecan at opencsw.org>:
>> What's the idea?
>
> The idea is this: if libstdc++.so.6 is in /opt/csw/lib and we
> automatically add -R/opt/csw/lib/$ISALIST to all binaries, there's a
> new failure mode: a binary might link against a SONAME traditionally
> from /usr/lib. If / when we introduce the an incompatible library with
> the same SONAME to /opt/csw/lib, we break that binary.
>
> State 1:
>
> /opt/csw/bin/foo NEEDED libbar.so.1, RPATH /opt/csw/lib
> /usr/lib/libbar.so.1 is available
>
> State 2:
>
> /opt/csw/bin/foo NEEDED libbar.so.1, RPATH /opt/csw/lib
> /usr/lib/libbar.so.1 is available
> /opt/csw/lib/libbar.so.1 is available too, incompatible with /opt/csw/bin/foo

Is a question of order, isn't it? Consequently, if /opt/csw/lib is
before /usr/lib, everything is dandy.

> I'm not sure if this is a scenario we have to worry about, because the
> solution is to keep GCC libraries in a subdirectory, which has its own
> disadvantages - library space fragmentation, sometimes harder to debug
> linking problems, etc.

The 3rd branch as the 4th, in the beginning, when I was the maintainer,
had this strategy and, as far as I remember, we hadn't an issue with. Am
I wrong?
-- 
Peter


More information about the devel mailing list