172799 2017-06-01 02:37:59 -0700 [GTK] [2.17.3] Fails to build in x86 2018-08-31 06:30:07 -0700 1 1 1 Unclassified WebKit WebKitGTK WebKit Nightly Build Unspecified Unspecified RESOLVED CONFIGURATION CHANGED P2 Normal --- 1 berto webkit-unassigned aperez bugs-noreply clopez mcatanzaro oldest_to_newest 1314563 0 berto 2017-06-01 02:37:59 -0700 x86_64 builds fine, but I'm having this error when trying to build it for x86: In file included from /tmp/webkit2gtk-2.17.3/Source/JavaScriptCore/interpreter/CallFrame.h:26:0, from /tmp/webkit2gtk-2.17.3/Source/JavaScriptCore/runtime/ClassInfo.h:25, from /tmp/webkit2gtk-2.17.3/Source/JavaScriptCore/runtime/Structure.h:28, from /tmp/webkit2gtk-2.17.3/Source/JavaScriptCore/runtime/ArrayStorage.h:33, from /tmp/webkit2gtk-2.17.3/Source/JavaScriptCore/runtime/ButterflyInlines.h:28, from /tmp/webkit2gtk-2.17.3/Source/JavaScriptCore/runtime/JSArray.h:24, from /tmp/webkit2gtk-2.17.3/Source/JavaScriptCore/bytecode/ArrayProfile.h:29, from /tmp/webkit2gtk-2.17.3/Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp:28: /tmp/webkit2gtk-2.17.3/Source/JavaScriptCore/interpreter/CalleeBits.h: In static member function 'static void* JSC::CalleeBits::boxWasm(JSC::Wasm::Callee*)': /tmp/webkit2gtk-2.17.3/Source/JavaScriptCore/interpreter/CalleeBits.h:54:81: error: 'TagBitsWasm' was not declared in this scope CalleeBits result(bitwise_cast<void*>(bitwise_cast<uintptr_t>(callee) | TagBitsWasm)); ^~~~~~~~~~~ /tmp/webkit2gtk-2.17.3/Source/JavaScriptCore/interpreter/CalleeBits.h: In member function 'bool JSC::CalleeBits::isWasm() const': /tmp/webkit2gtk-2.17.3/Source/JavaScriptCore/interpreter/CalleeBits.h:63:50: error: 'TagWasmMask' was not declared in this scope return (bitwise_cast<uintptr_t>(m_ptr) & TagWasmMask) == TagBitsWasm; ^~~~~~~~~~~ /tmp/webkit2gtk-2.17.3/Source/JavaScriptCore/interpreter/CalleeBits.h:63:66: error: 'TagBitsWasm' was not declared in this scope return (bitwise_cast<uintptr_t>(m_ptr) & TagWasmMask) == TagBitsWasm; ^~~~~~~~~~~ /tmp/webkit2gtk-2.17.3/Source/JavaScriptCore/interpreter/CalleeBits.h: In member function 'JSC::Wasm::Callee* JSC::CalleeBits::asWasmCallee() const': /tmp/webkit2gtk-2.17.3/Source/JavaScriptCore/interpreter/CalleeBits.h:80:78: error: 'TagBitsWasm' was not declared in this scope return bitwise_cast<Wasm::Callee*>(bitwise_cast<uintptr_t>(m_ptr) & ~TagBitsWasm); ^~~~~~~~~~~ Source/JavaScriptCore/CMakeFiles/LLIntOffsetsExtractor.dir/build.make:99: recipe for target 'Source/JavaScriptCore/CMakeFiles/LLIntOffsetsExtractor.dir/llint/LLIntOffsetsExtractor.cpp.o' failed 1314569 1 berto 2017-06-01 04:09:13 -0700 I think that the reason is that I'm building this on an x86_64 machine using an i386 chroot. In CMakeLists.txt, CMAKE_SYSTEM_PROCESSOR is defined by CMake using (I believe) "uname -m", which is x86_64 (the host CPU). if (MSVC_CXX_ARCHITECTURE_ID) string(TOLOWER ${MSVC_CXX_ARCHITECTURE_ID} LOWERCASE_CMAKE_SYSTEM_PROCESSOR) else () string(TOLOWER ${CMAKE_SYSTEM_PROCESSOR} LOWERCASE_CMAKE_SYSTEM_PROCESSOR) endif () if (LOWERCASE_CMAKE_SYSTEM_PROCESSOR MATCHES "^arm") set(WTF_CPU_ARM 1) [...] elseif (LOWERCASE_CMAKE_SYSTEM_PROCESSOR MATCHES "(x64|x86_64|amd64)") set(WTF_CPU_X86_64 1) elseif (LOWERCASE_CMAKE_SYSTEM_PROCESSOR MATCHES "(i[3-6]86|x86)") set(WTF_CPU_X86 1) [...] 1314580 2 aperez 2017-06-01 05:00:46 -0700 (In reply to Alberto Garcia from comment #1) > I think that the reason is that I'm building this on an x86_64 machine using > an i386 chroot. > > In CMakeLists.txt, CMAKE_SYSTEM_PROCESSOR is defined by CMake using (I > believe) "uname -m", which is x86_64 (the host CPU). > > if (MSVC_CXX_ARCHITECTURE_ID) > string(TOLOWER ${MSVC_CXX_ARCHITECTURE_ID} > LOWERCASE_CMAKE_SYSTEM_PROCESSOR) > else () > string(TOLOWER ${CMAKE_SYSTEM_PROCESSOR} > LOWERCASE_CMAKE_SYSTEM_PROCESSOR) > endif () > if (LOWERCASE_CMAKE_SYSTEM_PROCESSOR MATCHES "^arm") > set(WTF_CPU_ARM 1) > [...] > elseif (LOWERCASE_CMAKE_SYSTEM_PROCESSOR MATCHES "(x64|x86_64|amd64)") > set(WTF_CPU_X86_64 1) > elseif (LOWERCASE_CMAKE_SYSTEM_PROCESSOR MATCHES "(i[3-6]86|x86)") > set(WTF_CPU_X86 1) > [...] Passing “-m32” to the compiler under x86_64 is equivalent to cross-compiling. When cross-compiling using CMake one is supposed to supply a “toolchain file” which defines a few things, including the value for CMAKE_SYSTEM_PROCESSOR _for the target system_ (x86 in your case). See: https://cmake.org/Wiki/CMake_Cross_Compiling Now, having to provide a complete toolchain file sounds like a chore, but IIUC from the CMake documentation, you can as well pass the variables directly to the CMake invocation, and you could get away with something like: cmake path/to/sources -DCMAKE_SYSTEM_PROCESSOR=i686 ... In general CMake won't use the built-in default values for variables defined in the command line. I hope this helps. 1314584 3 berto 2017-06-01 05:10:54 -0700 (In reply to Adrian Perez from comment #2) > Passing “-m32” to the compiler under x86_64 is equivalent to > cross-compiling. I'm not doing that, I'm using a native 32-bit compiler. Everything inside the chroot is 32bit, just the kernel is 64bit. > Now, having to provide a complete toolchain file sounds like a chore, > but IIUC from the CMake documentation, you can as well pass the > variables directly to the CMake invocation, and you could get away > with something like: > > cmake path/to/sources -DCMAKE_SYSTEM_PROCESSOR=i686 ... Passing -DCMAKE_SYSTEM_PROCESSOR=XXX doesn't seem to solve the problem. 1314594 4 berto 2017-06-01 06:53:23 -0700 I confirm that using CMAKE_CXX_LIBRARY_ARCHITECTURE instead of CMAKE_SYSTEM_PROCESSOR solves the problem. I'm not sure if that's a good solution for all platforms supported by WebKit, so I can keep it as a Debian-specific workaround while we don't have the proper fix. 1426154 5 clopez 2018-05-22 07:54:00 -0700 Is this still an issue? I can successfully build webkit in an i386 container/schroot with Debian and as well cross-compile for i686 with Yocto (on an x86_64 host). Are you setting a 32 bit personality before starting the build? "uname -m" should return i686. If you use schroot you can set "personality=linux32" on the schroot config. If you use a raw chroot then you can prefix the build script/command with the "linux32" command. Example: $ uname -m x86_64 $ linux32 uname -m i686 1426155 6 clopez 2018-05-22 07:56:47 -0700 (In reply to Carlos Alberto Lopez Perez from comment #5) > If you use a raw chroot then you can prefix the build script/command with > the "linux32" command. > > Example: > > $ uname -m > x86_64 > > $ linux32 uname -m > i686 Or better... prefix the chroot command before entering into it so everything you execute into the container has the right personality by default: $ sudo linux32 chroot container_i386 1426168 7 berto 2018-05-22 08:52:20 -0700 (In reply to Carlos Alberto Lopez Perez from comment #5) > If you use a raw chroot then you can prefix the build script/command > with the "linux32" command. Ok, I didn't know that. Not sure how that would work with the Debian buildds, I need to see what's the current status.