/home/cgarcia/src/git/gnome/WebKit/WebKitBuild/Release/Source/WebKit2/tmp-introspecttMzAlB/WebKit2WebExtension-3.0.o:(.data+0x4b8): referencia a `webkit_dom_vtt_cue_get_type' sin definir (this is undefined reference in English)
collect2: error: ld returned 1 exit status
As you can see there's two -L/home/cgarcia/gnome/lib64, and the first one is very early an takes precedence. That first one comes from the LDFLAGS env varaibles that jhbuild sets. The other one, which is correctly set after the builddir paths, is deduced by g-ir-scanner from the lib arguments passed using ldd. This didn't happen with autotools because g-ir-scanner used libtool.
This is not a problem when using the internal jhbuild because we never run make install for webkit, only for the dependencies, so the linker never finds a installed webkit in jhbuild env.
Since we are already overriding the CFLAGS env var we can simply override LDFLAGS as well to unset it, since g-ir-scanner will do the right thing deducing all library paths using ldd.
Created attachment 230240 [details]
Comment on attachment 230240 [details]
Seems reasonable, though I wonder if some flags should be passed through. What is the value of LDFLAGS that is causing the incorrect link.
(In reply to comment #2)
> (From update of attachment 230240 [details])
> Seems reasonable, though I wonder if some flags should be passed through. What is the value of LDFLAGS that is causing the incorrect link.
$ jhbuild run env | grep LDFLAGS
That's added later guessed from the deps. We are already overriding the CFLAGS as well. jhbuild sets the LDFLAGS env var to make sure the programs compiled during configure build against the jhbuild environment. Note that this only affects the temporary files compiled by gobject-introspection to generate the gir files, so I'm pretty sure it's safe to override the LDFLAGS.
Committed r167873: <http://trac.webkit.org/changeset/167873>
Ignoring LDFLAGS causes build failure on FreeBSD because it cannot find libintl via LDFLAGS.