These should be going to the list for archiving, so I'm forwarding it.
On 4/29/18 8:32 AM, Dave Flogeras wrote:
Hey Anthony,
Also I'd like to chime in what I learned during testing: since this release of uclibc-ng-1.0.30 removes arcfour, rebuilding at least openssl/openssh immediately might warrant a huge warning for upgrading Gentoo users. My system is built on one machine and deployed as binaries onto the target, so having a non-working SSH/rsync after upgrading uclibc-ng is a bummer. Portage (Python) also squawks when importing a module until python is rebuilt, but it doesn't seem to prevent portage from working.
Dave
On Sun, Apr 29, 2018 at 6:24 AM, Waldemar Brodkorb wbx@uclibc-ng.org wrote:
Hi Anthony,
Dave and I fixed the dlclose() issue and we think it could be a good time to have new stage3 with 1.0.30? I can test on real hardware for every supported architecture.
Thanks in advance Waldemar
Yes I noticed that, and it is serious, but this is the least of my worries right now. The LDPATH search is totally broken on amd64. ldconfig shows that libstdc++.so and libgcc_s.so are in the search path:
# ldconfig -p | grep libstdc++.so libstdc++.so.6 (libc0) => /usr/lib/gcc/x86_64-gentoo-linux-uclibc/6.4.0/libstdc++.so.6 libstdc++.so (libc0) => /usr/lib/gcc/x86_64-gentoo-linux-uclibc/6.4.0/libstdc++.so
# ldconfig -p | grep libgcc_s.so libgcc_s.so.1 (libc0) => /usr/lib/gcc/x86_64-gentoo-linux-uclibc/6.4.0/libgcc_s.so.1
And yet a test c++ program cannot locate those libraries:
# ldd test libstdc++.so.6 => not found libgcc_s.so.1 => not found libc.so.0 => /lib//libc.so.0 (0x7f6bfb067000) ld64-uClibc.so.0 => /lib/ld64-uClibc.so.0 (0x7f6bfb516000)
@Waldemar, the issue is not anything you suggested in your previous email. What might you have touched in ld64-uClibc.so or libc.so itself that would affect the search path? If its any help, I hit the dlclose() issue many years ago (and might have been the first to report it, I'm not sure). There was some size issue wrt 64 vs 32 that cause an issue there. I wonder if in fixing that maybe you broke LDPATH?
On 4/29/18 8:49 AM, Anthony G. Basile wrote:
@Waldemar, the issue is not anything you suggested in your previous email. What might you have touched in ld64-uClibc.so or libc.so itself that would affect the search path? If its any help, I hit the dlclose() issue many years ago (and might have been the first to report it, I'm not sure). There was some size issue wrt 64 vs 32 that cause an issue there. I wonder if in fixing that maybe you broke LDPATH?
I need to add to this. The problem was introduced after 1.0.26 but before 1.0.28. Again, any clues as to which commits to look at? 1.0.27 fails to build on Gentoo amd64, so that's the best I could do with tagged releases.
Hi, Anthony G. Basile wrote,
On 4/29/18 8:49 AM, Anthony G. Basile wrote:
@Waldemar, the issue is not anything you suggested in your previous email. What might you have touched in ld64-uClibc.so or libc.so itself that would affect the search path? If its any help, I hit the dlclose() issue many years ago (and might have been the first to report it, I'm not sure). There was some size issue wrt 64 vs 32 that cause an issue there. I wonder if in fixing that maybe you broke LDPATH?
I need to add to this. The problem was introduced after 1.0.26 but before 1.0.28. Again, any clues as to which commits to look at? 1.0.27 fails to build on Gentoo amd64, so that's the best I could do with tagged releases.
Could you rebuild 1.0.26 with USE debug so that SUPPORT_LD_DEBUG is enabled. And then post the output of LD_DEBUG=all ./test
And then the same with 1.0.30?
I haven't used ldconfig/ld.so.cache on my systems before starting with Gentoo, so may be there something is broken or a regression.
best regards Waldemar
On 4/29/18 11:15 AM, Waldemar Brodkorb wrote:
Hi, Anthony G. Basile wrote,
On 4/29/18 8:49 AM, Anthony G. Basile wrote:
@Waldemar, the issue is not anything you suggested in your previous email. What might you have touched in ld64-uClibc.so or libc.so itself that would affect the search path? If its any help, I hit the dlclose() issue many years ago (and might have been the first to report it, I'm not sure). There was some size issue wrt 64 vs 32 that cause an issue there. I wonder if in fixing that maybe you broke LDPATH?
I need to add to this. The problem was introduced after 1.0.26 but before 1.0.28. Again, any clues as to which commits to look at? 1.0.27 fails to build on Gentoo amd64, so that's the best I could do with tagged releases.
Could you rebuild 1.0.26 with USE debug so that SUPPORT_LD_DEBUG is enabled. And then post the output of LD_DEBUG=all ./test
And then the same with 1.0.30?
I haven't used ldconfig/ld.so.cache on my systems before starting with Gentoo, so may be there something is broken or a regression.
best regards Waldemar
Right now I'm in the middle of doing a git bisect. After that I'll turn on ld_debug and see where I get.
Hi All, Anthony G. Basile wrote,
On 4/29/18 11:15 AM, Waldemar Brodkorb wrote:
Hi, Anthony G. Basile wrote,
On 4/29/18 8:49 AM, Anthony G. Basile wrote:
@Waldemar, the issue is not anything you suggested in your previous email. What might you have touched in ld64-uClibc.so or libc.so itself that would affect the search path? If its any help, I hit the dlclose() issue many years ago (and might have been the first to report it, I'm not sure). There was some size issue wrt 64 vs 32 that cause an issue there. I wonder if in fixing that maybe you broke LDPATH?
I need to add to this. The problem was introduced after 1.0.26 but before 1.0.28. Again, any clues as to which commits to look at? 1.0.27 fails to build on Gentoo amd64, so that's the best I could do with tagged releases.
Could you rebuild 1.0.26 with USE debug so that SUPPORT_LD_DEBUG is enabled. And then post the output of LD_DEBUG=all ./test
And then the same with 1.0.30?
I haven't used ldconfig/ld.so.cache on my systems before starting with Gentoo, so may be there something is broken or a regression.
So it was really a regression, I reverted the changeset: https://gogs.waldemar-brodkorb.de/oss/uclibc-ng/commit/92d250d387e247029900c...
Thanks Anthony for reporting the issue.
best regards Waldemar
-
Anthony G. Basile -
Anthony G. Basile -
Waldemar Brodkorb