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-uc…
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 : basile(a)freeharbor.net
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA