Summary: | >=net-libs/webkit-gtk-1.1.15 fails w/ USE="debug" -- undefined reference to `findDoctypeEntry(char const*, unsigned int)' | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Justin Lecher (RETIRED) <jlec> |
Component: | Current packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | dabbott, dajasu51, eric_chaligny, eXt, ivan, j.john.pease, jackdachef, jcdemay, johnwatjen, jsled, marduk, mjo, robert.bradbury, ruri, Thomas.Rausch |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://bugs.webkit.org/show_bug.cgi?id=29244 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
info.log
emerge --info for build with -j3 on webkit-gtk-1.2.5 Build log from failed webkit-gtk-1.4.1-r300 |
Description
Justin Lecher (RETIRED)
2009-12-01 13:11:12 UTC
Happens with 1.1.15.4 too? What about 1.1.17? (from the gnome overlay) (In reply to comment #1) > Happens with 1.1.15.4 too? What about 1.1.17? (from the gnome overlay) > Same. now this is getting weird: for me it's also failing but WITHOUT the "debug" use-flag with net-libs/webkit-gtk-1.1.19 from gnome-overlay until 1.1.18 it built fine use-flags: USE="coverage gstreamer pango -debug -doc (-introspection) ./.libs/libwebkit-1.0.so: undefined reference to `findDoctypeEntry(char const*, unsigned int)' ./.libs/libwebkit-1.0.so: undefined reference to `findEntity(char const*, unsigned int)' ./.libs/libwebkit-1.0.so: undefined reference to `findValue(char const*, unsigned int)' ./.libs/libwebkit-1.0.so: undefined reference to `findColor(char const*, unsigned int)' ./.libs/libwebkit-1.0.so: undefined reference to `findProp(char const*, unsigned int)' collect2: ld returned 1 exit status make[1]: *** [Programs/GtkLauncher] Error 1 make[1]: *** Waiting for unfinished jobs.... ./.libs/libwebkit-1.0.so: undefined reference to `findDoctypeEntry(char const*, unsigned int)' ./.libs/libwebkit-1.0.so: undefined reference to `findEntity(char const*, unsigned int)' ./.libs/libwebkit-1.0.so: undefined reference to `findValue(char const*, unsigned int)' ./.libs/libwebkit-1.0.so: undefined reference to `findColor(char const*, unsigned int)' ./.libs/libwebkit-1.0.so: undefined reference to `findProp(char const*, unsigned int)' collect2: ld returned 1 exit status make[1]: *** [Programs/DumpRenderTree] Error 1 make[1]: Leaving directory `/var/tmp/portage/net-libs/webkit-gtk-1.1.19/work/webkit-1.1.19' make: *** [all] Error 2 * ERROR: net-libs/webkit-gtk-1.1.19 failed: seems like webkit-gtk from now is behaving a little like www-client/chromium in regards to the toolchain: try adding -nopie to your CFLAGS/CXXFLAGS whether that fixes it I'm running the experimental hardened toolchain and switching to the hardenednopie profile "fixed" it (it compiled fine and I was able to compile midori with it) (In reply to comment #4) > seems like webkit-gtk from now is behaving a little like www-client/chromium in > regards to the toolchain: > > try adding -nopie to your CFLAGS/CXXFLAGS whether that fixes it > Thanks for that tip. I will report back when I tested it. *** Bug 271146 has been marked as a duplicate of this bug. *** This looks like the following bug report to me: https://bugs.webkit.org/show_bug.cgi?id=29244 *** Bug 307127 has been marked as a duplicate of this bug. *** FYI: I can't reproduce this error anymore after having updated gcc from 4.4.2 to 4.4.3 (from hardened overlay) and bumping the ebuild to the latest webkit-gtk snapshot 1.1.21 and 1.1.22 no need to build webkit-gtk anymore with -nopie or switching to the hardenednopie profile (in the hardened overlay) i hacked gperf, add a new "--disable-inline" option, and it works Created attachment 233231 [details]
info.log
Same issue, build.log is too big to paste:)
If any additional info is needed, post a comment
Same failure with 1.2.1 from gnome overlay. USE flags: websockets, gstreamer (In reply to comment #12) > Same failure with 1.2.1 from gnome overlay. > > > USE flags: websockets, gstreamer > Yes, we know, simply try to follow upstream bug report and you will see some progress there ;-) https://bugs.webkit.org/show_bug.cgi?id=29244 Patch from upstream: https://bugs.webkit.org/show_bug.cgi?id=29244#c47 *** Bug 332711 has been marked as a duplicate of this bug. *** So should I presume that the upstream patch is going to make it into a -1.2.3-r1 (and presumably -1.1.15-r1)? It should be noted that the flags I am using are "-debug", so the Summary regarding "USE="debug"" does not apply with at least 1.2.3 (which is why I one reason that I didn't simply append comments to a 1.1.15 bug report). If I understand the Webkit 29244 bug reports correctly it would appear that GTK fixes [green (GTK) classification) have been available since ~March. Any reason they haven't filtered down to Gentoo ebuilds? *** Bug 336120 has been marked as a duplicate of this bug. *** *** Bug 336176 has been marked as a duplicate of this bug. *** *** Bug 340999 has been marked as a duplicate of this bug. *** Hi Guys, any news in this bug? I have too. Thanks Alex (In reply to comment #20) > Hi Guys, > any news in this bug? > > I have too. > > Thanks > Alex > Here is what I had to do to resolve this bug on my system: I had to use this patch: http://pastebin.com/kZkV2h9R (silly, I know) I had to use CFLAGS="-march=athlon64 -O2 -pipe" And finally I had to compile at MAKEOPTS="-j1" I was unable to compile webkit-gtk 1.2.5 without doing all 3 of these steps. I can't apply the patch given in the above link on 1.2.3 ---------------------------------------- From ae3cb9fe3b352d235dd29e426ce7c68757daa1dd Mon Sep 17 00:00:00 2001 From: Andras Becsi <abecsi@inf.u-szeged.hu> Date: Fri, 3 Sep 2010 16:59:27 +0200 Subject: [PATCH] Undefined reference errors when linking due to gperf and inlining. --- ChangeLog | 20 ++++ WebCore/CMakeLists.txt | 11 ++- WebCore/ChangeLog | 34 +++++++ WebCore/WebCore.gyp/WebCore.gyp | 7 ++- WebCore/WebCore.pri | 4 +- WebCore/WebCore.vcproj/WebCore.vcproj | 20 ++++ WebCore/WebCore.xcodeproj/project.pbxproj | 8 ++ WebCore/css/CSSParser.cpp | 4 +- WebCore/css/makeprop.pl | 48 ++++++++-- WebCore/css/makevalues.pl | 50 +++++++++-- WebCore/html/DocTypeStrings.gperf | 18 +--- WebCore/html/HTMLDocument.cpp | 3 +- WebCore/make-hash-tools.pl | 103 +++++++++++++++++++++- WebCore/platform/ColorData.gperf | 11 +-- WebCore/platform/graphics/Color.cpp | 3 +- WebKit/qt/ChangeLog | 21 +++++ WebKit/qt/WebCoreSupport/FrameLoaderClientQt.cpp | 2 +- cmake/WebKitMacros.cmake | 19 +++- 18 files changed, 326 insertions(+), 60 deletions(-) ------------------------------------ There are not a "WebCore/WebCore.pri" in webkit-gtk-1.2.3 tarball... There is something I do not understand? After upgrading to gcc 4.5.1-r1 I was able to compile unpatched webkit-gtk-1.2.5 with makeopts="-j3" with CFLAGS="-march=athlon64 -O2 -pipe" (In reply to comment #23) > After upgrading to gcc 4.5.1-r1 I was able to compile unpatched > webkit-gtk-1.2.5 with makeopts="-j3" with CFLAGS="-march=athlon64 -O2 -pipe" > I have updated gcc to 4.5.1-r1 (without recompiling system and world) My CFLAGS are "-O2 -march=athlon-xp -pipe" I have changed /etc/portage/package.keywords to install webkit-gtk-1.2.5 Still the same error... (In reply to comment #24) > (In reply to comment #23) > > After upgrading to gcc 4.5.1-r1 I was able to compile unpatched > > webkit-gtk-1.2.5 with makeopts="-j3" with CFLAGS="-march=athlon64 -O2 -pipe" > > > > I have updated gcc to 4.5.1-r1 (without recompiling system and world) > My CFLAGS are "-O2 -march=athlon-xp -pipe" > I have changed /etc/portage/package.keywords to install webkit-gtk-1.2.5 > > Still the same error... > I'm sure you probably did, but did you make sure to select the new version of gcc with gcc-config x86_64-pc-linux-gnu-4.5.1 and then run env-update && source /etc/profile? (In reply to comment #25) > (In reply to comment #24) > > (In reply to comment #23) > > > After upgrading to gcc 4.5.1-r1 I was able to compile unpatched > > > webkit-gtk-1.2.5 with makeopts="-j3" with CFLAGS="-march=athlon64 -O2 -pipe" > > > > > > > I have updated gcc to 4.5.1-r1 (without recompiling system and world) > > My CFLAGS are "-O2 -march=athlon-xp -pipe" > > I have changed /etc/portage/package.keywords to install webkit-gtk-1.2.5 > > > > Still the same error... > > > > I'm sure you probably did, but did you make sure to select the new version of > gcc with gcc-config x86_64-pc-linux-gnu-4.5.1 and then run env-update && source > /etc/profile? > Yes, new version is selected with gcc-config. But curiously, I have no problem when compiling webkit-gtk manually. GtkLauncher is linked without problems. Where can be the difference between the two build? Interesting. The "-j3" comments got me interested... I have traditionally built gentoo over many years on a Pentium IV with -j2 with minimal problems. However when I built a moderately simple system on a Phenom II X3 with -j3 or -j4 I ran into several packages which would *not* build until I dropped the flags until -j1 [1]. That implies to me that there are "existence" dependencies which exist in the makefiles or tools which can appear to be satisfied on SMP systems which may not be fully satisfied as compiles proceed. This is further This looks like the reverse case (where multiple cores may be required in order to complete the build). Looking at the "undefined symbol" "findXyzzy" output which occurs with all 3 ebuilds (1.1.15.4, 1.2.3 and 1.2.5) I seem to find that in all cases the files which define these symbols (3 .c and 2 .cpp files) exist in the .../DerivedSources directory. But in only one of the 5 cases does a corresponding object file (libwebkit_1_0_la-HTMLEntityNames.o) which defines one of the missing symbols (findEntity) exist in the .../DerivedSources/.libs directory. This seems very very odd and has the odor of a dependency/timing problem. I run my emerges in "batch" mode, e.g. "chrt --batch 0 emerge ..." so I could easily see timing issues developing. Someone who actually got it to build successfully might try building it that way to see if it makes any difference. Also please in further bugs specify the # cores && -j# one is working with. Footnote: though I tried building it on the Phenom with -j3 and it failed with 3 identical sets of errors because it was trying to simultaneously load "testhttpbackend", "GtkLanncher" and DumpRenderTree. I would lean toward the command "CXXLD libwebkit-1.0.la" missing references to the objects/libraries that contain the undefined symbols. Ultimately someone who really understands the configure/Makefiles is probably going to have to take a look at this. The generalized commands (GEN, CC, CXXLD, etc.) make it very hard for people to know what is really going on behind the curtain. 1. Does make and its cousins simply look for an object file whose date is more recent than the source file? Or in SMP systems does it actually wait for the completion of any command which may be in the process of creating said object file? Even if it does this it would appear that complex make-rule-bypassed systems (webkit-gtk?) might fail when dealing with complex file build sequences. Created attachment 255737 [details]
emerge --info for build with -j3 on webkit-gtk-1.2.5
Fails with the same errors (undefined findXyzzy symbols) with 3 simultaneous "LD" commands.
I don't know how the "Add Archs" section of the bug report works but I strongly suspect since we are heading into the multi-core woods that there should be a "SMP" modifier to the architecture to allow people to search for builds with this kind of dependency problem. Though I have tried the two older ebuilds with "-j1" on the Phenom II X3 and they fail. Since one has to assume they must have worked at some point the problem is either in the tools or perhaps the patches and not-so-much in the webkit-gtk sources. This is to confirm that webkit-gtk does not currently appear to be makefile rule based dependency driven. If one changes to a failed build directory and does: make -j1 -f GNUmakefile one gets the typical load of GtkLauncher with the typical findXyzzy undefined symbol errors. If one removes .../.libs/libwebkit-1.0.* and issues the make command again it makes *no* attempt to rebuild libwebkit-1.0.* before attempting to load GtkLauncher. One is supposed to build the dependencies before one attempts a CCLD which requires them. *** Bug 351600 has been marked as a duplicate of this bug. *** Nothing helps. :'-( Also http://forums.gentoo.org/viewtopic-p-6219467.html#6219467 not. The cause is not to look for webkit-gtk itself, but in the dependencies to other packages: success in machine 1: completed emerge (39 of 185) net-libs/webkit-gtk-1.2.6 to / faild on machine 2: (186 of 338) Compiling/Packaging (net-libs/webkit-gtk-1.2.6 (In reply to comment #33) > success in machine 1: completed emerge (39 of 185) net-libs/webkit-gtk-1.2.6 to A subsequent emerge on a machine 1 then displays the same error. (In reply to comment #21) > I had to use CFLAGS="-march=athlon64 -O2 -pipe" My solution: "-O2". Other packages also require the "-pipe". Thats all. Webkit-gtk without optimization, is it to "-O1" that does not work. even "-O2 -pipe" does not work for me (In reply to comment #35) > (In reply to comment #21) > > I had to use CFLAGS="-march=athlon64 -O2 -pipe" > > My solution: "-O2". Other packages also require the "-pipe". Thats all. > Webkit-gtk without optimization, is it to "-O1" that does not work. > *** Bug 357469 has been marked as a duplicate of this bug. *** *** Bug 367463 has been marked as a duplicate of this bug. *** Is there a working solution to this yet? Midori keeps crashing on me and I suspect the segfault is in webkit-gtk. But, when I try to recompile with CFLAGS="-pipe -ggdb", I hit this bug. This bug also affects webkit-gtk-1.2.7, a possibly alternative is to try webkit-gtk-1.4.x. People, please try with 1.4.1-r200 Created attachment 276971 [details]
Build log from failed webkit-gtk-1.4.1-r300
webkit-gtk-1.4.1-r300 also fails, but in a different way (should I open a new bug?). Attaching gzipped build log due to bigness.
Yes, the failure is different and, then, a new bug should be opened for it. About original problem, upstream fixed it in 1.4.x |