On 18 Aug 2016, at 11:15, Tijl Coosemans <t...@freebsd.org> wrote: > > On Wed, 17 Aug 2016 14:17:10 -0700 Steve Kargl > <s...@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
