Bug 25836 – libwebkit from svn doesn't build (revision 43796)

• Status: RESOLVED
• Resolution: INVALID
• Component: WebKitGTK

[Hussam Al-Tayeb]

webkit svn revision 43796 doesn't build on linux. I get the following build error:


/bin/mkdir -p ./.deps/DerivedSources
./doltlibtool --tag=CXX   --mode=link g++ -fno-strict-aliasing -O2 -fvisibility-inlines-hidden -fno-rtti -Wall -W -Wcast-align -Wchar-subscripts -Wreturn-type -Wformat -Wformat-security -Wno-format-y2k -Wundef -Wmissing-format-attribute -Wpointer-arith -Wwrite-strings -Wno-unused-parameter -Wno-parentheses -fno-exceptions -fvisibility=hidden  -D_REENTRANT -I/usr/include -O2   -o Programs/jsc JavaScriptCore/Programs_jsc-jsc.o libJavaScriptCore.la 
libtool: link: g++ -fno-strict-aliasing -O2 -fvisibility-inlines-hidden -fno-rtti -Wall -W -Wcast-align -Wchar-subscripts -Wreturn-type -Wformat -Wformat-security -Wno-format-y2k -Wundef -Wmissing-format-attribute -Wpointer-arith -Wwrite-strings -Wno-unused-parameter -Wno-parentheses -fno-exceptions -fvisibility=hidden -D_REENTRANT -I/usr/include -O2 -o Programs/jsc JavaScriptCore/Programs_jsc-jsc.o  ./.libs/libJavaScriptCore.a -L/usr/lib -licui18n -licuuc -licudata -lgobject-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lpthread -pthread
./.libs/libJavaScriptCore.a(libJavaScriptCore_la-JSClassRef.o): In function `OpaqueJSClass::create(JSClassDefinition const*)':
JSClassRef.cpp:(.text+0xa14): undefined reference to `__sync_fetch_and_add_4'
./.libs/libJavaScriptCore.a(libJavaScriptCore_la-JSClassRef.o): In function `OpaqueJSClassContextData::~OpaqueJSClassContextData()':
JSClassRef.cpp:(.text+0x1485): undefined reference to `__sync_fetch_and_add_4'
./.libs/libJavaScriptCore.a(libJavaScriptCore_la-JSClassRef.o): In function `OpaqueJSClassContextData::~OpaqueJSClassContextData()':
JSClassRef.cpp:(.text+0x1615): undefined reference to `__sync_fetch_and_add_4'
./.libs/libJavaScriptCore.a(libJavaScriptCore_la-JSClassRef.o): In function `WTF::ThreadSafeShared<OpaqueJSString>::deref()':
JSClassRef.cpp:(.text._ZN3WTF16ThreadSafeSharedI14OpaqueJSStringE5derefEv[WTF::ThreadSafeShared<OpaqueJSString>::deref()]+0x26): undefined reference to `__sync_fetch_and_add_4'
./.libs/libJavaScriptCore.a(libJavaScriptCore_la-JSClassRef.o): In function `JSC::JSCallbackObject<JSC::JSObject>::deleteProperty(JSC::ExecState*, JSC::Identifier const&)':
JSClassRef.cpp:(.text._ZN3JSC16JSCallbackObjectINS_8JSObjectEE14deletePropertyEPNS_9ExecStateERKNS_10IdentifierE[JSC::JSCallbackObject<JSC::JSObject>::deleteProperty(JSC::ExecState*, JSC::Identifier const&)]+0x2a3): undefined reference to `__sync_fetch_and_add_4'
./.libs/libJavaScriptCore.a(libJavaScriptCore_la-JSClassRef.o):JSClassRef.cpp:(.text._ZN3JSC16JSCallbackObjectINS_8JSObjectEE18getOwnPropertySlotEPNS_9ExecStateERKNS_10IdentifierERNS_12PropertySlotE[JSC::JSCallbackObject<JSC::JSObject>::getOwnPropertySlot(JSC::ExecState*, JSC::Identifier const&, JSC::PropertySlot&)]+0x174): more undefined references to `__sync_fetch_and_add_4' follow
collect2: ld returned 1 exit status
make[1]: *** [Programs/jsc] Error 1
make[1]: Leaving directory `/home/hussam/packages/libwebkit/src/webkit-build'

[Xan Lopez]

I have never seen this. What platform/architecture/toolchain are you using?

[Hussam Al-Tayeb]

linux, 32bit. gcc 4.4, glibc 2.10 and binutils 2.19.1
the 1.1.7 source tarball builds fine http://webkitgtk.org/webkit-1.1.7.tar.gz
I don't know why it doesn't build from svn.

[Jordan Callicoat]

Same problem here. Linux 32bit (2.6.29), gcc 4.4.0, libc 2.10.1, binutils 2.19.1.

From a bit of googling, it appears that gcc is generating the wrong asm because it can't figure out the arch, so it's generating for 64bit. If I export "-march=i686" in CFLAGS/CPPFLAGS/CXXFLAGS before calling configure I can at least get it to compile, but then during linking I get the following error:

libtool: link: ar cru .libs/libWebCoreJS.a DerivedSources/.libs/JSCSSCharsetRule.o [lots of other files...] DerivedSources/.libs/JSSVGZoomEvent.o 
ar: DerivedSources/.libs/JSCSSCharsetRule.o: No such file or directory
make[1]: *** [libWebCoreJS.la] Error 1
make[1]: Leaving directory `/tmp/builds/WebKit'
make: *** [all] Error 2

None of the object files are in DerivedSources/.libs (or anywhere in the tree). There are a few object files there, but none of the ones that it's looking for.

$ ls DerivedSource/.libs/
libWebCore_la-CSSGrammar.o                   libWebCore_la-SVGNames.o
libWebCore_la-HTMLElementFactory.o           libWebCore_la-UserAgentStyleSheetsData.o
libWebCore_la-HTMLEntityNames.o              libWebCore_la-XLinkNames.o
libWebCore_la-HTMLNames.o                    libWebCore_la-XMLNames.o
libWebCore_la-JSHTMLElementWrapperFactory.o  libWebCore_la-XPathGrammar.o
libWebCore_la-JSSVGElementWrapperFactory.o   libwebkit_1_0_la-webkitenumtypes.o
libWebCore_la-SVGElementFactory.o            libwebkit_1_0_la-webkitmarshal.o

Can't find anything helpful on google. :(

Ps. I get the error even after a fresh pull into a new directory, using the following command line to configure:

$ CPPFLAGS="-march=i686" CXXFLAGS="-march=i686" CFLAGS="-march=i686" ./autogen.sh --prefix=/usr --enable-gnomekeyring

[Jordan Callicoat]

(In reply to comment #3)
> Same problem here. Linux 32bit (2.6.29), gcc 4.4.0, libc 2.10.1, binutils
> 2.19.1.
> [snip]

Hmm. I just tried building with the build-webkit script in a clean tree, and it worked.

$ CPPFLAGS="-march=i686" CXXFLAGS="-march=i686" CFLAGS="-march=i686" WebKitTools/Scripts/build-webkit --release --gtk --gnomekeyring
[snip]
===========================================================
 WebKit is now built.

Didn't try it without the *FLAGS vars. Maybe something wonky with autotools when using ./autogen.sh? (I'm on Arch with automake 1.11, autoconf 2.63)

[Jordan Callicoat]

For posterity, this is what currently works for me to build and install WebKit:

$ WebKitInstallationPrefix=/usr \
CPPFLAGS="-march=i686" \
CXXFLAGS="-march=i686" \
CFLAGS="-march=i686" \
WebKitTools/Scripts/build-webkit \
--release --gtk --gnomekeyring

$ cd WebKitBuild/Release

$ sudo make install

[Jordan Callicoat]

After some more digging it appears that the gcc version in Arch (4.4.0-20090505) is the source of the problem: http://bugs.archlinux.org/task/14825

[Jordan Callicoat]

Given that Hussam was also using Arch with the same buggy GCC build (see http://bugs.archlinux.org/task/14825), this bug should be marked as invalid.

[Hussam Al-Tayeb]

Closed as INVALID.