On 4/28/18 3:43 PM, Waldemar Brodkorb wrote:
> Hi,
>
> I released uClibc-ng 1.0.30 today.
> Many thanks to Dave Flogeras who pushed me to my limits to
> get the annyoing dlclose() issue fixed.
>
I have not been successfully able to update uclibc-ng past 1.0.26 on
Gentoo because of various issues. I was hoping 1.0.30 would fix these,
but its even worse. So far I've tested amd64 and i686. On amd64 I'm
getting a situation where /etc/ld.so.cache is not being respected.
Gentoo places libstdc++.so at
/usr/lib/gcc/x86_64-gentoo-linux-uclibc/6.4.0. ld.so.conf looks like
the following
/usr/lib/gcc/x86_64-gentoo-linux-uclibc/6.4.0
/lib
/usr/lib
/usr/local/lib
There is no problem compiling c++ however, it can't link at runtime:
# echo "int main() { return 0; }" > test.cpp
# g++ -o test test.cpp
# ./test
/root/test: can't load library 'libstdc++.so.6'
# LD_LIBRARY_PATH=/usr/lib/gcc/x86_64-gentoo-linux-uclibc/6.4.0 ./test
#
So I'm in the situation where in order to build a gentoo system using
uclibc-ng on amd64, I must pass LD_LIBRARY_PATH env var to emerge, not
to mention any other executables consuming libstdc++. This effects
packages like gmp, eudev and other critical core packages. Its
important to note that I do not have this issue with i686. I'll try to
test arm and ppc later.
A lot of the linking code has been touched. I could do a git bisect but
I don't have the time to dedicate to this. Any clue on the fix?
--
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
