[Webkit-unassigned] [Bug 172799] [GTK] [2.17.3] Fails to build in x86

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=172799

Adrian Perez <aperez at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aperez at igalia.com

--- Comment #2 from Adrian Perez <aperez at igalia.com> ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170601/95daaa68/attachment.html>