On 4/29/18 6:52 AM, Waldemar Brodkorb wrote: > > Why I have these symlinks in my Gentoo amd64 system: > ls -la /usr/lib/libstdc++.so* > lrwxrwxrwx 1 root root 51 Jan 28 14:58 /usr/lib/libstdc++.so -> > ./gcc/x86_64-gentoo-linux-uclibc/7.2.0/libstdc++.so > lrwxrwxrwx 1 root root 53 Jan 28 14:58 /usr/lib/libstdc++.so.6 -> > ./gcc/x86_64-gentoo-linux-uclibc/7.2.0/libstdc++.so.6 > lrwxrwxrwx 1 root root 58 Jan 28 14:58 /usr/lib/libstdc++.so.6.0.24 > -> ./gcc/x86_64-gentoo-linux-uclibc/7.2.0/libstdc++.so.6.0.24 > wbx@tin ~ $
These sym links are wrong and we can't really live with them because of how we build stuff in Gentoo. We have to be able to use ld.so.conf. This problem is worst with libstdc++.so, but there are numerous packages that will break unless ld.so.conf works. > > May be I added them when having issues. :( > > When the uClibc-ng ldconfig has issues, may be this commit is > the culprit? > 2a3bb4daf5778c5875674cd26a3c75b3d460a042 > > All other ldso changes where dlclose() related. > > best regards > Waldemar I can look at that. If possible, can you periodically test against stock stage3's obtained at the following. Those are the stage3's I maintain. The are all built on native hardware. https://distfiles.gentoo.org/releases/amd64/autobuilds/current-stage3-amd64-uclibc-hardened/ https://distfiles.gentoo.org/releases/x86/autobuilds/current-stage3-i686-uclibc-hardened/ https://distfiles.gentoo.org/experimental/arm/uclibc/ https://distfiles.gentoo.org/experimental/ppc/uclibc/ https://distfiles.gentoo.org/experimental/mips/uclibc/mips32r2/ https://distfiles.gentoo.org/experimental/mips/uclibc/mipsel3/ -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : bas...@freeharbor.net GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA _______________________________________________ devel mailing list devel@uclibc-ng.org https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
