| Summary: | media-libs/harfbuzz-5.3.1 don't compile (icu related?) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Serge <net1957> |
| Component: | Current packages | Assignee: | Gentoo Office Team <office> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | gnome, net1957, sam |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=880405 https://github.com/harfbuzz/harfbuzz/pull/3870 https://bugs.gentoo.org/show_bug.cgi?id=830966 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 880681 | ||
| Bug Blocks: | |||
| Attachments: |
emerge --info
emerge -pqv build.log environnment |
||
|
Description
Serge
2022-11-08 20:26:56 UTC
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! |
