on the system, harfbuzz 5.1.0 is installed but a @world update fail to update it to 5.3.1 Reproducible: Always Steps to Reproduce: 1. emerge -uDavt --newuse --deep @world 2. 3. Actual Results: it fail on fail on harfbuzz-5.3.1 Expected Results: it should complie
Created attachment 829479 [details] emerge --info
Created attachment 829481 [details] emerge -pqv
Created attachment 829483 [details] build.log
Created attachment 829485 [details] environnment
x86_64-pc-linux-gnu-g++ -m32 -mfpmath=sse -o src/libharfbuzz-icu.so.0.50301.0 src/libharfbuzz-icu.so.0.50301.0.p/hb-icu.cc.o -Wl,--as-needed -Wl,--no-undefined -shared -fPIC -Wl,--start-group -Wl,-soname,libharfbuzz-icu.so.0 -march=native -O2 -pipe -std=c++14 -Wl,-O1 -Wl,--as-needed '-Wl,-rpath,$ORIGIN/' -Wl,-rpath-link,/var/tmp/portage/media-libs/harfbuzz-5.3.1/work/harfbuzz-5.3.1-abi_x86_32.x86/src src/libharfbuzz.so.0.50301.0 /usr/lib64/libicuuc.so -Wl,--end-group /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libicuuc.so: error adding symbols: file in wrong format collect2: error: ld returned 1 exit status
Please don't CC arches manually.
There's some totally bogus stuff going on here. The main problem is you specifically said "no I do not want ICU" and here it is, giving you ICU. Via cmake, because heck why not. I daren't imagine how the cmake support code works at the best of times, nor why cmake is finding a 64-bit ICU as part of a 32-bit build, but heck, there you are. I have submitted https://github.com/harfbuzz/harfbuzz/pull/3870 to fix it.
its a AMD64 system using some 32bits app portage for icu is: [ebuild R ] dev-libs/icu-71.1-r1:0/71.1::gentoo USE="-debug -doc -examples -static-libs -test -verify-sig" ABI_X86="(64) -32 (-x32)" portage for harfbuzz: [ebuild U ] media-libs/harfbuzz-5.3.1:0/4.0.0::gentoo [5.1.0:0/4.0.0::gentoo] USE="cairo glib graphite introspection truetype -debug -doc -experimental -icu -test" ABI_X86="32 (64) (-x32)" icu is only ABI_X86 64 but hafbuzz is ABI_X86 32 and 64 could it be a problem ? perhaps icu need also the ABI_X86 32 and 64 ?
tried it on the latest version and it compile fine with -icu flag but compile icu part... not a big problem. sk-srv ~ # lddtree /usr/lib/libharfbuzz-icu.so.0.50301.0 libharfbuzz-icu.so.0.50301.0 => /usr/lib/libharfbuzz-icu.so.0.50301.0 (interpreter => none) libharfbuzz.so.0 => /usr/lib/libharfbuzz.so.0 libm.so.6 => /lib/libm.so.6 ld-linux.so.2 => /lib/ld-linux.so.2 libfreetype.so.6 => /usr/lib/libfreetype.so.6 libbz2.so.1 => /usr/lib/libbz2.so.1 libpng16.so.16 => /usr/lib/libpng16.so.16 libz.so.1 => /usr/lib/libz.so.1 libgraphite2.so.3 => /usr/lib/libgraphite2.so.3 libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 libpcre2-8.so.0 => /usr/lib/libpcre2-8.so.0 libicuuc.so.71 => /usr/lib/libicuuc.so.71 libicudata.so.71 => /usr/lib/libicudata.so.71 libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/32/libstdc++.so.6 libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/32/libgcc_s.so.1 libc.so.6 => /lib/libc.so.6 sk-srv ~ # lddtree /usr/lib64/libharfbuzz-icu.so.0.50301.0 libharfbuzz-icu.so.0.50301.0 => /usr/lib64/libharfbuzz-icu.so.0.50301.0 (interpreter => none) libharfbuzz.so.0 => /usr/lib64/libharfbuzz.so.0 libm.so.6 => /lib64/libm.so.6 ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 libfreetype.so.6 => /usr/lib64/libfreetype.so.6 libbz2.so.1 => /lib64/libbz2.so.1 libpng16.so.16 => /usr/lib64/libpng16.so.16 libz.so.1 => /lib64/libz.so.1 libgraphite2.so.3 => /usr/lib64/libgraphite2.so.3 libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 libpcre2-8.so.0 => /usr/lib64/libpcre2-8.so.0 libicuuc.so.71 => /usr/lib64/libicuuc.so.71 libicudata.so.71 => /usr/lib64/libicudata.so.71 libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/libstdc++.so.6 libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/libgcc_s.so.1 libc.so.6 => /lib64/libc.so.6
(In reply to Serge from comment #9) but icu need the abi_x86_32 use flag. without it harfbuzz fail same as before
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9e5d8576d295164bc6dc9873e68ed94fd46968cf commit 9e5d8576d295164bc6dc9873e68ed94fd46968cf Author: Sam James <sam@gentoo.org> AuthorDate: 2022-11-10 05:13:32 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-11-10 05:14:03 +0000 media-libs/harfbuzz: backport fix for icu/freetype detection Bug: https://bugs.gentoo.org/830966 Closes: https://bugs.gentoo.org/880405 Closes: https://bugs.gentoo.org/880479 Thanks-to: Eli Schwartz <eschwartz93@gmail.com> Signed-off-by: Sam James <sam@gentoo.org> .../files/harfbuzz-5.3.1-meson-freetype-icu.patch | 120 +++++++++++++++++++++ media-libs/harfbuzz/harfbuzz-5.3.1-r1.ebuild | 104 ++++++++++++++++++ 2 files changed, 224 insertions(+)
nice! it compile now and respect the icu use flag
(In reply to Serge from comment #12) > nice! > > it compile now and respect the icu use flag Eli is a star :) I'll kick off stabilisation of that fixed version now, I just wanted to let it bake in ~arch for a few hours in case of anything unexpected. Thanks for confirming it's OK!
