Problems with out libgcc_s.so in base

[Dimitry Andric]

On 18 Aug 2016, at 11:15, Tijl Coosemans <tijl at FreeBSD.org> wrote:
> 
> On Wed, 17 Aug 2016 14:17:10 -0700 Steve Kargl <sgk at troutmask.apl.washington.edu> wrote:
...
>> % ldconfig -r | grep libgcc
>>        6:-lgcc_s.1 => /lib/libgcc_s.so.1
>>        735:-lgcc_s.1 => /usr/local/lib/gcc6/libgcc_s.so.1
>> 
>> Clearly, ldd is looking for 735 but finds 6.  If the lang/gcc6 could
>> be convinced to build, install, and use libgcc_s6.so.1, then the
>> problem is solved without a wrapper.
> 
> In this case the real cause of the problem is that compilers and linkers
> search /lib and /usr/lib last and ldconfig searches them first.  Renaming
> the library is just a hack around that.

Well, even if you would adjust the compilers and linkers to look in
/usr/local/lib first, how would you solve the problem of having
multiple, possibly incompatible versions of the same library in
different directories?

For example, on one of my systems, I now have these:

/usr/local/lib/gcc47/libgcc_s.so.1
/usr/local/lib/gcc48/libgcc_s.so.1
/usr/local/lib/gcc49/libgcc_s.so.1
/usr/local/lib/gcc5/libgcc_s.so.1
/usr/local/lib/gcc6/libgcc_s.so.1
/usr/local/lib/gcc7/libgcc_s.so.1

So which one are you going to put at the front of the path?  The gcc7
version?  If you are lucky that one is backwards compatible with all the
previous ones, but still I would like it much better if a program
compiled by, say, gcc5 was linked *explicitly* against the gcc5 version
of libgcc_s.so.

Steve's proposed scheme solves that quite nicely, in my opinion.  The
problem is only in the details, as usual.  There will be many configure
scripts and libtool-like utilities out there, that assume libgcc must be
linked using -lgcc_s, not -lgcc_s$VERSION.

-Dimitry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20160818/cfae09df/attachment.sig>