Bug 172799 - [GTK] [2.17.3] Fails to build in x86
Summary: [GTK] [2.17.3] Fails to build in x86
Status: RESOLVED CONFIGURATION CHANGED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-06-01 02:37 PDT by Alberto Garcia
Modified: 2018-08-31 06:30 PDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alberto Garcia 2017-06-01 02:37:59 PDT
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
Comment 1 Alberto Garcia 2017-06-01 04:09:13 PDT
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)
   [...]
Comment 2 Adrian Perez 2017-06-01 05:00:46 PDT
(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.
Comment 3 Alberto Garcia 2017-06-01 05:10:54 PDT
(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.
Comment 4 Alberto Garcia 2017-06-01 06:53:23 PDT
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.
Comment 5 Carlos Alberto Lopez Perez 2018-05-22 07:54:00 PDT
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
Comment 6 Carlos Alberto Lopez Perez 2018-05-22 07:56:47 PDT
(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
Comment 7 Alberto Garcia 2018-05-22 08:52:20 PDT
(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.