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.
Short summary: 748422473 (HEAD -> master, tag: v1.0.30, origin/master, origin/HEAD, github/master) bump for release 1.0.30 3f100edcc mention Tile architecture 14be0795f libdl: first execute all destructors, then munmap library 132decd2a libdl: calculate the length for second parameter of munmap. 04a676f3c linuxthreads: implement pthread_condattr_{s,g}etclock() d86bd3529 libdl: end must be bigger than start 8d7723d1c libdl: remove gcc warnings d89de5cba libiconv: remove function, which is not available w/o libiconv a4 macros 35105679b libdl: fix problem with unmapping eb560ac79 libdl: better checking and logging for ctors/dtors 744e199bb libdl: remove dead code 0c8cc6e7e libdl: remove LDSO_NO_CLEANUP 07dfe7c86 libdl: cleanup old inline changelog aaf1b2f56 Revert "libdl: fix dlclose() issue" 343fb004d common/sendfile.c: bugfix can't support offset is NULL 2d8a38e1a Revert "common/sendfile.c: bugfix can't support offset is NULL" ad6c75c47 lseek.c: bugfix ltp lseek01.c b00fd230e common/sendfile.c: bugfix can't support offset is NULL f42d18f06 or1k: add F_{DUPFD_CLOEXEC, SETPIPE_SZ, GETPIPE_SZ} 161d237ad use __NR_newfstatat only for modern Linux architectures 91e21d251 hppa: fix runtime issues 8be3a69f1 csky: support bsd-setjmp and bsd-_setjmp. bf4c2d242 libdl: fix dlclose() issue 5bdc2b4de Revert "Revert "libdl: fix size parameter when unmap library in dlclose"" 490e84f5e tile: add basic support for tilegx 6e627523e sparc32: Add nop before __startcontext to stop unwinding 01e9f2f20 utils: fix compile of msgfmt/msgmerge c03cce8f7 fenv: only allow for ppc e500
best regards Waldemar
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?
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
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/
-
Anthony G. Basile -
Waldemar Brodkorb