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-...
https://distfiles.gentoo.org/releases/x86/autobuilds/current-stage3-i686-ucl...
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/