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

[Maciej (Matchek) Bliziński]

2012/1/15 Peter FELECAN <pfelecan at opencsw.org>:
>> /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.

If /opt/csw/lib is first, then /opt/csw/lib/libbar.so.1 will be loaded
first, and /opt/csw/bin/foo will crash (it was linked against
/usr/lib/libbar.so.1).

>> 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?

My latest thoughts are that the above failure scenario is possible,
but is quite contrived and unlikely. It also assumes that we need to
support old binaries indefinitely. I understand that Solaris has the
backward binary compatibility policy, but this is not one our goals,
if I'm not mistaken. If we really run into a linking problem, we'll
rebuild the failing binaries. If we can't rebuild a package, then
library location is not the worst of our troubles.

So, I'm leaning towards keeping all libraries in /opt/csw/lib,
including libgcc_s and libstdc++.

Maciej