I've been experiencing for some time the following kind of linking errors when building WebKitGTK+ in certain scenarios (e.g. trying to build it with build-webkit inside a jhbuild shell environment for GNOME development over a Ubuntu 12.04 64bit machine): ./.libs/libwebkit2gtk-3.0.so: undefined reference to `hb_icu_script_to_script' Investigating a bit the issue I realized the problem was that the -lharfbuzz parameter was not present in the linking lines, which was the cause of the error. Investigating a bit further I found out that the $(FREETYPE_CFLAGS) and $(FREETYPE_LIBS) variables were not being added in most of the places in GNUMakefile.am files where binaries were built, so that's why the -lharfbuzz parameter was not added. I'm still not sure why this issue is not spotted in some other environments (doing a clean build with build-webkit script *outside* my jhbuild for GNOME does not hit the issue) but it seems interesting to me in any case to add these flags to GNUMakefile.am files where needed, since that fixes the issue in these other specific cases, while it leaves the other scenarios working properly as well.
Created attachment 185209 [details] Patch proposal This patch fixes the issue for me.
Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See http://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API
Comment on attachment 185209 [details] Patch proposal I think you might be overlinking here. You only need to add it to libraries/binaries that didn't compile.
(In reply to comment #3) > (From update of attachment 185209 [details]) > I think you might be overlinking here. You only need to add it to libraries/binaries that didn't compile. :-) That's precisely what I did: instead of wildly adding things in every makefile I could find, what I did was precisely to go step by step by trying to build with make -j1 V=1 (debug build) and fix every single problem I found, one after one. So, long way of saying that every single FREETYPE_LIBS line you see in this patch corresponds to an actual failure I've found while trying to build, so this is the minimum patch I got that fixes the build for this scenario.
Comment on attachment 185209 [details] Patch proposal Sorry! I really should converted my statement into a question, but I was only starting my first coffee. :)
(In reply to comment #5) > (From update of attachment 185209 [details]) > Sorry! I really should converted my statement into a question, but I was only starting my first coffee. :) No problem. Thanks in any case for reviewing it!
Committed r141126: <http://trac.webkit.org/changeset/141126>
I know we do it for other libraries right now, but we shouldn't really need to explicitly link those libraries into binaries that link to webkitgtk, wonder why it's not working for you.
(In reply to comment #8) > I know we do it for other libraries right now, but we shouldn't really need to explicitly link those libraries into binaries that link to webkitgtk, wonder why it's not working for you. That's a really good point.
(In reply to comment #8) > I know we do it for other libraries right now, but we shouldn't really need to > explicitly link those libraries into binaries that link to webkitgtk, wonder > why it's not working for you. It's working for me as long as I call build-webkit --gtk from a normal shell but it fails when I invoke that script from a -already present- jhbuild shell (e.g. GNOME's jhbuild shell). For some reason, the -lharfbuzz flag is missing in this case and so the libharfbuzz.so file is not being added to the linking, resulting in the failure shown above. In any case, please feel free to rollback the patch if you don't feel comfortable with it. If it's just me (or very rare cases) who is getting this trouble I can certainly work it around in some other (local) way.
Nah, I'm just wondering. Like I said, we do it for other libraries and I don't care about purity, tbh.
(In reply to comment #10) > (In reply to comment #8) > > I know we do it for other libraries right now, but we shouldn't really need to > explicitly link those libraries into binaries that link to webkitgtk, wonder > > why it's not working for you. > > It's working for me as long as I call build-webkit --gtk from a normal shell but it fails when I invoke that script from a -already present- jhbuild shell (e.g. GNOME's jhbuild shell). > > For some reason, the -lharfbuzz flag is missing in this case and so the libharfbuzz.so file is not being added to the linking, resulting in the failure shown above. > > In any case, please feel free to rollback the patch if you don't feel comfortable with it. If it's just me (or very rare cases) who is getting this trouble I can certainly work it around in some other (local) way. Hey, I got the same error while linking webkit2gtk against Gnome's gitg using jhbuild, can you guys help me out? /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../lib/libwebkit2gtk-3.0.so: undefined reference to `hb_icu_script_to_script' /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../lib/libwebkit2gtk-3.0.so: undefined reference to `hb_icu_get_unicode_funcs' collect2: error: ld returned 1 exit status
(In reply to comment #12) > Hey, I got the same error while linking webkit2gtk against Gnome's > gitg using jhbuild, can you guys help me out? Looks like you're talking about bug 116978
(In reply to comment #12) > /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../lib/libwebkit2gtk-3.0.so: undefined reference to `hb_icu_script_to_script' > /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../lib/libwebkit2gtk-3.0.so: undefined reference to `hb_icu_get_unicode_funcs' > collect2: error: ld returned 1 exit status It sounds like the version of harfbuzz you are using was not compiled with ICU support.
(In reply to comment #14) > > /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../lib/libwebkit2gtk-3.0.so: undefined reference to `hb_icu_script_to_script' > > /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../lib/libwebkit2gtk-3.0.so: undefined reference to `hb_icu_get_unicode_funcs' > > collect2: error: ld returned 1 exit status > > It sounds like the version of harfbuzz you are using was not > compiled with ICU support. Yes, that's because the latest HarfBuzz moved ICU to a separate library. Details in bug 116978.
(In reply to comment #14) > (In reply to comment #12) > > > /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../lib/libwebkit2gtk-3.0.so: undefined reference to `hb_icu_script_to_script' > > /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../lib/libwebkit2gtk-3.0.so: undefined reference to `hb_icu_get_unicode_funcs' > > collect2: error: ld returned 1 exit status > > It sounds like the version of harfbuzz you are using was not compiled with ICU support. It's the bug 116978, after downgrade harfbuzz, get it working. Now need to wait webkit to fix it.