Hi Anthony, Anthony G. Basile wrote,
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?
I am not sure any change in uClibc-ng is related to this issue.
Could it be a configuration change I introduced while trying to get icu4c compilation fixed: @@ -121,21 +121,19 @@ SUPPORT_LD_DEBUG_EARLY UCLIBC_HAS_CTYPE_UNSAFE UCLIBC_HAS_LOCALE - UCLIBC_HAS_SSP_COMPAT + LDSO_SAFE_RUNPATH )
# These are forced on defs_y=( - COMPAT_ATEXIT DO_C99_MATH DO_XSI_MATH FORCE_SHAREABLE_TEXT_SEGMENTS LDSO_GNU_HASH_SUPPORT - LDSO_PRELINK_SUPPORT LDSO_PRELOAD_FILE_SUPPORT + LDSO_RUNPATH LDSO_RUNPATH_OF_EXECUTABLE LDSO_STANDALONE_SUPPORT
Either LDSO_SAFE_RUNPATH or LDSO_RUNPATH might change the behaviour of ld.so.
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 ~ $
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