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
_______________________________________________
devel mailing list
devel@uclibc-ng.org
https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
