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

Anthony G. Basile basile at freeharbor.net
Sun Apr 29 11:31:09 CEST 2018


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?

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : basile at freeharbor.net
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



More information about the devel mailing list