Bug 172799 – [GTK] [2.17.3] Fails to build in x86

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: WebKitGTK

[Alberto Garcia]

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

[Alberto Garcia]

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)
   [...]

[Adrian Perez]

(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.

[Alberto Garcia]

(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.

[Alberto Garcia]

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.

[Carlos Alberto Lopez Perez]

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

[Carlos Alberto Lopez Perez]

(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

[Alberto Garcia]

(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.