Created attachment 443678 [details] gzipped build.log how to reproduce grab a recent stage 3, unpack, chroot in and emerge dev-libs/icu. this happens with arm and x86, cannot test on amd64 because that stage3 tarball is broken
Created attachment 443680 [details] emerge.info
Please... run the build again, and when it has failed, * cd into the build directory, /var/tmp/portage/dev-libs/icu-57.1/work/icu/source-abi_x86_32.x86 * find in there libicutu.so.57 * run "ldd -r pathtothelibrary/libicutu.so.57" and add the output here... Also, does the problem still happen with icu-58.1-r1 ?
Correction... > Please... run the build again, and when it has failed, > > * cd into the build directory, > /var/tmp/portage/dev-libs/icu-57.1/work/icu/source-abi_x86_32.x86 > > * find in there libicutu.so.57 > * cd into that directory * run "LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH ldd -r ./libicutu.so.57" > > and add the output here... > > Also, does the problem still happen with icu-58.1-r1 ?
on an ARM system, the libicutu.so.57 is to be found in /var/tmp/portage/dev-libs/icu-57.1/work/icu/source-.arm/lib/ ; if I run LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH ldd -r ./libicutu.so.57 from this path I get the following output root lib # LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH ldd -r ./libicutu.so.57 -r: -r: No such file or directory ./libicutu.so.57: checking sub-depends for 'libicui18n.so.57' checking sub-depends for 'libicuuc.so.57' checking sub-depends for '/usr/lib/gcc/armv7a-hardfloat-linux-uclibceabi/4.9.4/libstdc++.so.6' checking sub-depends for '/usr/lib/gcc/armv7a-hardfloat-linux-uclibceabi/4.9.4/libgcc_s.so.1' checking sub-depends for '/lib/libc.so.0' ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x54b65000) libicui18n.so.57 => libicui18n.so.57 (0x00000000) libicuuc.so.57 => libicuuc.so.57 (0x00000000) libstdc++.so.6 => /usr/lib/gcc/armv7a-hardfloat-linux-uclibceabi/4.9.4/libstdc++.so.6 (0x00000000) libgcc_s.so.1 => /usr/lib/gcc/armv7a-hardfloat-linux-uclibceabi/4.9.4/libgcc_s.so.1 (0x00000000) libc.so.0 => /lib/libc.so.0 (0x00000000) /lib/ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x00000000) /lib/ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x00000000) with icu-58.1-r1 root lib # LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH ldd -r ./libicutu.so.58 libicutu.so.58 libicutu.so.58.1 root lib # LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH ldd -r ./libicutu.so.58.1 -r: -r: No such file or directory ./libicutu.so.58.1: checking sub-depends for 'libicui18n.so.58' checking sub-depends for 'libicuuc.so.58' checking sub-depends for '/usr/lib/gcc/armv7a-hardfloat-linux-uclibceabi/4.9.4/libstdc++.so.6' checking sub-depends for '/usr/lib/gcc/armv7a-hardfloat-linux-uclibceabi/4.9.4/libgcc_s.so.1' checking sub-depends for '/lib/libc.so.0' ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x54b24000) libicui18n.so.58 => libicui18n.so.58 (0x00000000) libicuuc.so.58 => libicuuc.so.58 (0x00000000) libstdc++.so.6 => /usr/lib/gcc/armv7a-hardfloat-linux-uclibceabi/4.9.4/libstdc++.so.6 (0x00000000) libgcc_s.so.1 => /usr/lib/gcc/armv7a-hardfloat-linux-uclibceabi/4.9.4/libgcc_s.so.1 (0x00000000) libc.so.0 => /lib/libc.so.0 (0x00000000) /lib/ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x00000000) /lib/ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x00000000)
Same thing happens to me with icu-58.1-r1. I'll attach the relevant info.
Created attachment 461458 [details] build.log
Created attachment 461460 [details] emerge --info
Created attachment 461462 [details] emerge -pqv
Created attachment 461464 [details] environment
Created attachment 461466 [details] ldd -r
(In reply to Dave Kennedy from comment #5) > Same thing happens to me with icu-58.1-r1. I'll attach the relevant info. The failing command (I also have the problem on uclibc-ng 1.0.17) is LD_LIBRARY_PATH=../lib:../stubdata:../tools/ctestfw:$LD_LIBRARY_PATH ../bin/icupkg -d ./out/build/icudt58l --list -x \* /var/tmp/portage/dev-libs/icu-58.1-r1/work/icu/source/data/in/icudt58l.dat -o out/tmp/icudata.lst However, when I replace the relative paths that are set to LD_LIBRARY_PATH with their absolute counterparts, the command succeeds.
Created attachment 463294 [details, diff] icu-58.1-uclibcng.patch After searching though the Makefiles, I found out where the relative paths come from. In GNU make, there is a function to convert relative paths to absolute paths. Working on native uclibc-ng 1.0.17 hardened AMD64. Can someone test a cross-compile?
I tested your patch on nativ arm, which doesn't work unfortunately. Will provide the full build log later on, fyi I am using uclibc-ng-1.0.20 with activated symlink-compat useflag. make -f pkgdataMakefile armv7a-hardfloat-linux-uclibceabi-gcc ... /var/tmp/portage/dev-libs/icu-58.1-r1/work/icu/source/extra/uconv/uwmsg.c armv7a-hardfloat-linux-uclibceabi-g++ ... /var/tmp/portage/dev-libs/icu-58.1-r1/work/icu/source/extra/uconv/uconv.cpp mkdir uconvmsg LD_LIBRARY_PATH=../../lib:../../stubdata:../../tools/ctestfw:$LD_LIBRARY_PATH ../../bin/genrb -e UTF-8 -s /var/tmp/portage/dev-libs/icu-58.1-r1/work/icu/source/extra/uconv/resources -d uconvmsg root.txt make[3]: Entering directory '/var/tmp/portage/dev-libs/icu-58.1-r1/work/icu/source-.arm/extra/uconv' rm -rf pkgdata.inc /var/tmp/portage/dev-libs/icu-58.1-r1/work/icu/source-.arm/bin/genrb: can't load library 'libicutu.so.58' Makefile:175: recipe for target 'uconvmsg/root.res' failed make[2]: *** [uconvmsg/root.res] Error 16 make[2]: *** Waiting for unfinished jobs.... make[3]: Leaving directory '/var/tmp/portage/dev-libs/icu-58.1-r1/work/icu/source-.arm/extra/uconv' make[2]: Leaving directory '/var/tmp/portage/dev-libs/icu-58.1-r1/work/icu/source-.arm/extra/uconv' Makefile:49: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 2 make[1]: Leaving directory '/var/tmp/portage/dev-libs/icu-58.1-r1/work/icu/source-.arm/extra' Makefile:143: recipe for target 'all-recursive' failed make: *** [all-recursive] Error 2
Something similar happened to me with dev-libs/icu-58.1-r1 on a uclibc-hardened installation. The offending lines seem to be this: LD_LIBRARY_PATH=../lib:../stubdata:../tools/ctestfw:$LD_LIBRARY_PATH ../bin/icupkg -d ./out/build/icudt58l --list -x \* /var/tmp/portage/dev-libs/icu-58.1-r1/work/icu/source/data/in/icudt58l.dat -o out/tmp/icudata.lst /var/tmp/portage/dev-libs/icu-58.1-r1/work/icu/source-abi_x86_64.amd64/bin/icupkg: can't load library 'libicutu.so.58' That one's fixed by invoking emerge as such: LD_LIBRARY_PATH=/var/tmp/portage/dev-libs/icu-58.1-r1/work/icu/source-abi_x86_64.amd64/lib emerge icu But a new error happened: LD_LIBRARY_PATH=../lib:../stubdata:../tools/ctestfw:$LD_LIBRARY_PATH ../bin/icupkg -d ./out/build/icudt58l --list -x \* /var/tmp/portage/dev-libs/icu-58.1-r1/work/icu/source/data/in/icudt58l.dat -o out/tmp/icudata.lst /var/tmp/portage/dev-libs/icu-58.1-r1/work/icu/source-abi_x86_64.amd64/bin/icupkg: can't load library 'libicudata.so.58' So I appended the location of libicudata: LD_LIBRARY_PATH=/var/tmp/portage/dev-libs/icu-58.1-r1/work/icu/source-abi_x86_64.amd64/lib:/var/tmp/portage/dev-libs/icu-58.1-r1/work/icu/source-abi_x86_64.amd64/stubdata emerge icu And now it compiles. Temporarily I work around this needing explicit LD_LIBRARY_PATH by using the package.env mechanism. Would be nice if it can be fixed without a workaround.
indeed, the issuee can be solved by setting the LD_LIBRARY path for an arm system, it is LD_LIBRARY_PATH=/var/tmp/portage/dev-libs/icu-58.1-r1/work/icu/source-.arm/lib:/var/tmp/portage/dev-libs/icu-58.1-r1/work/icu/source-.arm/stubdata
This is probably related to bug #608312 where LD_LIBRARY_PATH isn't properly parsed. I'll see if I can narrow it down this summer when I get some time.
Created attachment 499016 [details, diff] icu-hack-makefile-use-absolute-LD_LIBRARY-path.patch I think René is on the right track. Here is a tweaked version which works for me for icu-58.2-r1
Instead of patching every ebuild to use absolute PATH in LD_LIBRARY_PATH, why LDSO_SAFE_RUNPATH is not simply added to defs_n in the uclibc-ng ebuild? Not loading a library from a relative path is a feature, not a bug. Works for me this way, tested on amd64.
Same problem with llvm by the way.
Is this still a problem with current versions?
Created attachment 675625 [details] compressed build log
yes, this is still a problem. also with brandnew icu-68.1
closing in favour of #630598 , which has working patch *** This bug has been marked as a duplicate of bug 630598 ***
