[uclibc-ng-devel] uClibc-ng 1.0.30 released

Waldemar Brodkorb wbx at uclibc-ng.org
Sun Apr 29 12:52:34 CEST 2018


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 at 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



More information about the devel mailing list