Hi, after update media-libs/harfbuzz chromium fails to run with: chromium-browser: undefined symbol: hb_icu_get_unicode_funcs and when i try to recompile www-client/chromium it fails also, flock out/Release/linker.lock x86_64-pc-linux-gnu-g++ -Wl,-z,now -Wl,-z,relro -pthread -Wl,-z,noexecstack -fPIC -pie -Lout/Release -Wl,--export-dynamic -pthread -Wl,--export-dynamic -pth$ out/Release/obj.target/third_party/WebKit/Source/core/core.gyp/../../../../../webcore_platform/third_party/WebKit/Source/core/platform/graphics/harfbuzz/HarfBuzzShaper.o: En la función `We$ HarfBuzzShaper.cpp:(.text._ZN7WebCore14HarfBuzzShaper17shapeHarfBuzzRunsEb+0x20): referencia a `hb_icu_get_unicode_funcs' sin definir out/Release/obj.target/third_party/WebKit/Source/core/core.gyp/../../../../../webcore_platform/third_party/WebKit/Source/core/platform/graphics/harfbuzz/HarfBuzzShaper.o: En la función `We$ HarfBuzzShaper.cpp:(.text._ZN7WebCore14HarfBuzzShaper19collectHarfBuzzRunsEv+0x2d0): referencia a `hb_icu_script_to_script' sin definir collect2: error: ld devolvió el estado de salida 1 make: *** [out/Release/chrome] Error 1 i just mask media-libs/harfbuzz-0.9.18, downgrade to 0.9.17 and things work again. Salud. Reproducible: Always emerge --info: http://bpaste.net/show/104622 build log chromium attached.
Created attachment 350218 [details] chromium build log
add >=media-libs/harfbuzz-0.9.18 icu to /etc/portage/package.use harfbuzz has gained a new flag "icu" which is not on by default
already have icu USE on: [ebuild U ] media-libs/harfbuzz-0.9.18 [0.9.17] USE="cairo%* glib%* graphite%* icu%* truetype%* -static-libs" 0 kB is on global USEs as you can see on my emerge --info.
sorry missed that .. but checking all the new flags cairo -- set icu --set truetype --set glib -- not set graphite -- not set .. glib was orignally always set, now it is a flag .. graphite was also always set, it is also a flag as well please try setting these and see this resolves the issue..
those 2 are set also when i update, 0.9.18 ebuild: IUSE="+cairo +glib +graphite icu static-libs +truetype" from harfbuzz-0.9.18 configure log: Build configuration: Unicode callbacks (you want at least one): Glib: true ICU: true UCDN: false Font callbacks (the more the better): FreeType: true Tools used for command-line utilities: Cairo: true Additional shapers (the more the better): Graphite2: true
Same problem here. The whole compilation process is fine, but the final link step at the end fails: out/Release/obj.target/third_party/WebKit/Source/core/core.gyp/../../../../../webcore_platform/third_party/WebKit/Source/core/platform/graphics/harfbuzz/HarfBuzzShaper.o: In function `WebCore::HarfBuzzShaper::shapeHarfBuzzRuns(bool)': HarfBuzzShaper.cpp:(.text._ZN7WebCore14HarfBuzzShaper17shapeHarfBuzzRunsEb+0x1d): undefined reference to `hb_icu_get_unicode_funcs' out/Release/obj.target/third_party/WebKit/Source/core/core.gyp/../../../../../webcore_platform/third_party/WebKit/Source/core/platform/graphics/harfbuzz/HarfBuzzShaper.o: In function `WebCore::HarfBuzzShaper::collectHarfBuzzRuns()': HarfBuzzShaper.cpp:(.text._ZN7WebCore14HarfBuzzShaper19collectHarfBuzzRunsEv+0x2c0): undefined reference to `hb_icu_script_to_script' This happens with the "icu" USE flag of harfbuzz enabled or disabled (tried both.)
I'm also
It looks like that symbol moved from libharfbuzz.so to libharfbuzz-icu.so. This creates an ABI break, and should have been accompanied by a subslot change. If this change is intentional, the chromium build process will need to be updated to pass -lharfbuzz-icu to the linker when building against this version of harfbuzz.
Darn yes it needs subslot, they did it on purpose, i missed it.
(In reply to Mike Gilbert from comment #8) > It looks like that symbol moved from libharfbuzz.so to libharfbuzz-icu.so. > This creates an ABI break, and should have been accompanied by a subslot > change. And upstream should bump SONAME. I filed https://bugs.freedesktop.org/show_bug.cgi?id=65432 for this. > If this change is intentional, the chromium build process will need to be > updated to pass -lharfbuzz-icu to the linker when building against this > version of harfbuzz. Working on a fix, https://codereview.chromium.org/16172008/ . I think we'll need to apply it as a custom patch - I'm going to do that after it lands upstream.
(In reply to Tomáš Chvátal from comment #9) > Darn yes it needs subslot, they did it on purpose, i missed it. But this will not fix packages linking only against libharfbuzz correct?
(In reply to Markos Chandras from comment #11) > But this will not fix packages linking only against libharfbuzz correct? Right. Maybe we should mask this harfbuzz release for a bit?
(In reply to Mike Gilbert from comment #12) > (In reply to Markos Chandras from comment #11) > > But this will not fix packages linking only against libharfbuzz correct? > > Right. Maybe we should mask this harfbuzz release for a bit? Sounds good to me
*** Bug 472448 has been marked as a duplicate of this bug. ***
(In reply to Mike Gilbert from comment #12) > (In reply to Markos Chandras from comment #11) > > But this will not fix packages linking only against libharfbuzz correct? > > Right. Maybe we should mask this harfbuzz release for a bit? As far as I can see, there are 5 packages in portage that are using harfbuzz: app-office/libreoffice, media-libs/libass, net-libs/webkit-gtk, www-client/chromium, and x11-libs/pango. Of these, libass and pango certainly do not use any harfbuzz-icu symbols. Libreoffice appears to work fine with 0.9.18 also. So the packages affected by the harfbuzz-icu change are webkit-gtk-2.0.x (which is masked) and chromium. Does it make sense to mask 0.9.18 for the sake of one unmasked package?
(In reply to Alexandre Rostovtsev from comment #15) > Does it make sense to mask 0.9.18 for the sake of one unmasked package? Well, put another way, harbuzz-0.9.18 breaks 20% of its reverse dependencies. ;) It looks like phajdan's patch has been reviewed and accepted upstream, so it it should not be a problem much longer.
harfbuzz-0.9.18-r1 now has a subslot, and webkit-gtk-2.0.2 has been patched for 0.9.18 compatibility. +*harfbuzz-0.9.18-r1 (06 Jun 2013) + + 06 Jun 2013; Alexandre Rostovtsev <tetromino@gentoo.org> + -harfbuzz-0.9.18.ebuild, +harfbuzz-0.9.18-r1.ebuild, harfbuzz-9999.ebuild: + Add a subslot due to ABI change (some symbols moved to libharfbuzz-icu), bug + #472416.
I test the patch for chromium via /etc/portage/patches and now compile and works fine with harfbuzz-0.9.18. Thanks.
I'll work on adding the patch to the tree; if someone else is working on this, please let me know.
Quick and dirty way for someone who is already stuck there with failing chromium build and doesn't want to wait for whole chromium to rebuild now: sed 's/lharfbuzz/lharfbuzz -lharfbuzz-icu/g' -i \ <your-workdir>/www-client/chromium-28.0.1500.20/work/chromium-28.0.1500.20/chrome/chrome.target.mk ebuild /usr/portage/www-client/chromium/chromium-28.0.1500.20.ebuild merge
(In reply to Mike Gilbert from comment #19) > I'll work on adding the patch to the tree; if someone else is working on > this, please let me know. 06 Jun 2013; Pawel Hajdan jr +files/chromium-system-harfbuzz-r0.patch, chromium-28.0.1500.20.ebuild, chromium-29.0.1521.3.ebuild, chromium-9999-r1.ebuild: Fix build with system harfbuzz-0.9.18, bug #472416 by Ivan Atienza. I had it tested yesterday, but only got a chance to commit today. The dependency also works with harfbuzz-0.9.12, isn't that cool? :)
Hm, new error: third_party/WebKit/Source/core/platform/graphics/harfbuzz/HarfBuzzShaper.cpp:40:20: fatal error: hb-icu.h: No such file or directory compilation terminated.
Ah, I think it's because chromium doesn't depend on the "icu" USE flag of harfbuzz. By default it's disabled so building it against a "-icu" >=harfbuzz-0.9.18 will fail.
(In reply to Nikos Chantziaras from comment #23) > Ah, I think it's because chromium doesn't depend on the "icu" USE flag of > harfbuzz. By default it's disabled so building it against a "-icu" > >=harfbuzz-0.9.18 will fail. Yes it does. Check to make sure you have the updated version. # $Header: /var/cvsroot/gentoo-x86/www-client/chromium/chromium-28.0.1500.20.ebuild,v 1.3 2013/06/06 16:45:18 phajdan.jr Exp $ RDEPEND="... media-libs/harfbuzz:=[icu(+)] ..."
Feel free to change the use defaults. Altho it should build against icu, but not use icu-le.
I'd like to point out that this still affects chromium-27.0.1453.110 (the latest stable version).
(In reply to Maks Verver from comment #26) > I'd like to point out that this still affects chromium-27.0.1453.110 (the > latest stable version). You must not mix stable and testing ebuilds
On chrome 29 it's work/chromium-29.0.1521.3/out/Release/obj/chrome/chrome.ninja that needs to be edited as per comment 20
www-client/chromium-29.0.1521.3 still fails with: third_party/WebKit/Source/core/platform/graphics/harfbuzz/HarfBuzzShaper.cpp:40:20: fatal error: hb-icu.h: No such file or directory compilation terminated. ninja: build stopped: subcommand failed. :(
*** Bug 472518 has been marked as a duplicate of this bug. ***
(In reply to Kamen Dokov from comment #29) Once again, make sure your portage tree is up to date with the latest change by phajdan.jr, and make sure you have the icu use flag enabled for media-libs/harfbuzz.
*** Bug 472568 has been marked as a duplicate of this bug. ***
+ 07 Jun 2013; Mike Gilbert <floppym@gentoo.org> -chromium-27.0.1453.93.ebuild, + chromium-27.0.1453.110.ebuild: + Place upper-bound on harfbuzz dep, bug 472416. Remove old.
(In reply to Mike Gilbert from comment #31) ... and make sure you have the icu use flag enabled for > media-libs/harfbuzz. That was it, thank you!
jhbuild uses a following patch for webkit, maybe it's relevant jhbuild/patches/webkitgtk-fix-harfbuzz-icu.patch https://bugs.webkit.org/show_bug.cgi?id=116978 diff --git a/Source/autotools/FindDependencies.m4 b/Source/autotools/FindDependencies.m4 index a9067c5..aead295 100644 --- a/Source/autotools/FindDependencies.m4 +++ b/Source/autotools/FindDependencies.m4 @@ -373,6 +373,13 @@ PKG_CHECK_MODULES([FREETYPE], [cairo-ft fontconfig >= fontconfig_required_version freetype2 >= freetype2_required_version harfbuzz >= harfbuzz_required_version]) fi +# HarfBuzz 0.9.18 splits harbuzz-icu into a separate library. +# Since we support earlier HarfBuzz versions we keep this conditional for now. +if $PKG_CONFIG --atleast-version 0.9.18 harfbuzz; then + PKG_CHECK_MODULES(HARFBUZZ_ICU, harfbuzz-icu >= $harfbuzz_required_version) + FREETYPE_CFLAGS+=" $HARFBUZZ_ICU_CFLAGS" + FREETYPE_LIBS+=" $HARFBUZZ_ICU_LIBS" +fi AC_SUBST([FREETYPE_CFLAGS]) AC_SUBST([FREETYPE_LIBS])