[GTK] WK does not compile properly against libxslt
Created attachment 208544 [details] Patch Fixes the -lm match problem when linking against libxslt.
(In reply to comment #1) > Created an attachment (id=208544) [details] > Patch > > Fixes the -lm match problem when linking against libxslt. The math symbols cannot be found though libxslt needs them and the cause is that we are not acknowledging its flags.
Comment on attachment 208544 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=208544&action=review > Source/WebKit/gtk/ChangeLog:3 > + [GTK] WK does not compile properly against libxslt Nit: you should say link instead of compile
Created attachment 208635 [details] Patch Fixes the -lm match problem when linking against libxslt.
If this gets again the r+, I could set cq tomorrow.
Comment on attachment 208635 [details] Patch Clearing flags on attachment: 208635 Committed r154041: <http://trac.webkit.org/changeset/154041>
All reviewed patches have been landed. Closing bug.
This still happens to me with Debian testing: /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libxslt.so: error: undefined reference to 'fmod' /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libxslt.so: error: undefined reference to 'floor' /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libxslt.so: error: undefined reference to 'pow' collect2: error: ld returned 1 exit status make[1]: *** [Programs/unittests/testdomdomwindow] Error 1 The only way I managed to build was adding -lm explicitly to WK1 tests, MiniBrowser and WTR makefiles. Adding LIBXSLT_LIBS doesn't seem to be enough here. I wonder why it works in the bots, though.
(In reply to comment #8) > This still happens to me with Debian testing: > > /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libxslt.so: error: undefined reference to 'fmod' > /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libxslt.so: error: undefined reference to 'floor' > /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libxslt.so: error: undefined reference to 'pow' > collect2: error: ld returned 1 exit status > make[1]: *** [Programs/unittests/testdomdomwindow] Error 1 > > The only way I managed to build was adding -lm explicitly to WK1 tests, MiniBrowser and WTR makefiles. Adding LIBXSLT_LIBS doesn't seem to be enough here. I wonder why it works in the bots, though. Yes, you need to recompile libxslt, because the one in your system doesn't have -lm when you do a pkg-config --libs libxslt . The one upstream does.
(In reply to comment #9) > (In reply to comment #8) > > This still happens to me with Debian testing: > > > > /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libxslt.so: error: undefined reference to 'fmod' > > /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libxslt.so: error: undefined reference to 'floor' > > /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libxslt.so: error: undefined reference to 'pow' > > collect2: error: ld returned 1 exit status > > make[1]: *** [Programs/unittests/testdomdomwindow] Error 1 > > > > The only way I managed to build was adding -lm explicitly to WK1 tests, MiniBrowser and WTR makefiles. Adding LIBXSLT_LIBS doesn't seem to be enough here. I wonder why it works in the bots, though. > > Yes, you need to recompile libxslt, because the one in your system doesn't have -lm when you do a pkg-config --libs libxslt . The one upstream does. This is rather annoying. Shouldn't we (for now) put libxslt in our jhbuild? I'd like to avoid "all" our Debian users to rebuild a system-wide lib...
(In reply to comment #10) > This is rather annoying. Shouldn't we (for now) put libxslt in our jhbuild? I'd like to avoid "all" our Debian users to rebuild a system-wide lib... We could, but if we go for current master, we need to apply https://bugzilla.gnome.org/show_bug.cgi?id=706882 .
*** Bug 121282 has been marked as a duplicate of this bug. ***
A workaround is to add -lm to the Libs: section in /usr/lib/*/pkgconfig/libxslt.pc See also http://bugs.debian.org/721602
This patch seems wrong, because it's adding libxslt to the linker line of binaries that do not use it directly.
(In reply to comment #14) > This patch seems wrong, because it's adding libxslt to the linker line of binaries that do not use it directly. Okay, after our IRC conversation I've been trying to understand the whole thing. I've just reverted this patch (r154041) and compiled WebKit again from scratch but I didn't notice anything wrong. Xabier, what was exactly the original problem you were trying to solve with this?
I just filed bug 121356 in order to revert this and other XSLT changes.