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?