Bug 169886 – [Linux] determineArchitecture is not cross-compile aware

• Status: RESOLVED
• Resolution: FIXED
• Component: Tools / Tests

[Carlos Alberto Lopez Perez]

The  determineArchitecture() subroutine determines the architecture of the build host rather than the target arch (at least on Linux).

This causes that isX86_64() return true if the host build is an amd64 machine, ignoring if the build host is cross-building.

So when using build-webkit or build-jsc the tooling may end passing options to the build that shouldn't be enabled, like enabling FTL_JIT because it defaults to true on x86_64, and the tooling confuses build_host=x86_64 with target_arch=armv7.

[Michael Catanzaro]

Does build-webkit have any options to set separate host/target architectures for cross compiling?

I have not investigated it, but I would be surprised if build-webkit (or build-jsc) was intended for use in cross-compiling. I would have instructed users to use CMake directly instead. If you're cross-compiling you most likely want a production build rather than a development build, after all.

[Carlos Alberto Lopez Perez]

(In reply to comment #1)
> Does build-webkit have any options to set separate host/target architectures
> for cross compiling?
> 
> I have not investigated it, but I would be surprised if build-webkit (or
> build-jsc) was intended for use in cross-compiling. I would have instructed
> users to use CMake directly instead. If you're cross-compiling you most
> likely want a production build rather than a development build, after all.

The intent is to run buildbots that cross-build. All WebKit buildbots build webkit with the script build-webkit (or build-jsc if they only build JSC).

And some architectures are not really powerful, having to build webkit natively on those its beyond reasonable. So the only solution that remains is cross-build.

The current JSCOnly ARM bots http://build.webkit.org/waterfall?category=misc are currently cross-building, and we are setting up a MIPS bot for JSCOnly also (initially).  I'm not sure if they are not hitting this issue (ENABLE_FTL_JIT=ON is passed in the cmakeargs because hostOS==amd64) because the hostOS is a 32-bit one (i686) in their case, or for some other workaround that I missed.

[Carlos Alberto Lopez Perez]

Created attachment 304962 [details]
Patch

[Csaba Osztrogonác]

(In reply to comment #2)

> The current JSCOnly ARM bots http://build.webkit.org/waterfall?category=misc
> are currently cross-building, and we are setting up a MIPS bot for JSCOnly
> also (initially).  I'm not sure if they are not hitting this issue
> (ENABLE_FTL_JIT=ON is passed in the cmakeargs because hostOS==amd64) because
> the hostOS is a 32-bit one (i686) in their case, or for some other
> workaround that I missed.

The current JSCOnly ARMv7 and ARMv8 bots run on X86_64 servers inside
ARM chroots and almost everything is emulated with qemu. But we have
some tricks to speedup the build, we use some statically linked X86_64
binaries inside the chroots, for example: cross-gcc (with icecc),
pkg-config, bash, svn, cmake, ninja, ...

Otherwise it would be great if build-jsc could support cross-compiling
out of the box.

[Csaba Osztrogonác]

Comment on attachment 304962 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=304962&action=review

> Tools/Scripts/webkitdirs.pm:-1191
> -sub isARM()
> -{
> -    return ($Config{archname} =~ /^arm[v\-]/) || ($Config{archname} =~ /^aarch64[v\-]/);
> -}

You are right, it is dead code now. But maybe we would need isARMv7() and isARMv8() 
in the future in build-jsc and/or FeatureList.pm similar to isX86_64().

But they can be added easily later, simple copy/paste of the actual isX86_64().

[Carlos Alberto Lopez Perez]

(In reply to Csaba Osztrogonác from comment #4)
> (In reply to comment #2)
> 
> > The current JSCOnly ARM bots http://build.webkit.org/waterfall?category=misc
> > are currently cross-building, and we are setting up a MIPS bot for JSCOnly
> > also (initially).  I'm not sure if they are not hitting this issue
> > (ENABLE_FTL_JIT=ON is passed in the cmakeargs because hostOS==amd64) because
> > the hostOS is a 32-bit one (i686) in their case, or for some other
> > workaround that I missed.
> 
> The current JSCOnly ARMv7 and ARMv8 bots run on X86_64 servers inside
> ARM chroots and almost everything is emulated with qemu. But we have
> some tricks to speedup the build, we use some statically linked X86_64
> binaries inside the chroots, for example: cross-gcc (with icecc),
> pkg-config, bash, svn, cmake, ninja, ...
> 
> Otherwise it would be great if build-jsc could support cross-compiling
> out of the box.

Thats an interesting approach to the problem, it also solves the ldd problem, as run-jsc-stress-tests runs ldd over the binary to get the list of libraries it should copy to the test target machine. And having ldd working otherwise its more tricky. Thanks for the info.

[Carlos Alberto Lopez Perez]

Comment on attachment 304962 [details]
Patch

Clearing flags on attachment: 304962

Committed r214250: <http://trac.webkit.org/changeset/214250>

[Carlos Alberto Lopez Perez]

All reviewed patches have been landed.  Closing bug.

[Loïc Yhuel]

Note that isCrossCompilation would return 0 for :
 - clang (which can even be multi target)
 - x86_64 multiarch, ie CC="gcc -m32" (in this case "gcc -m32 -dumpmachine" would return the wrong value anyway)

With cmake, it is recommended to use a toolchain file when cross-compiling, ie --cmakeargs="-DCMAKE_TOOLCHAIN_FILE=xxxx".
The toolchain file can then set CMAKE_SYSTEM_PROCESSOR (but --system-information mode doesn't accept arguments, so it cannot be tested without generating a normal project).

[Carlos Alberto Lopez Perez]

(In reply to Loïc Yhuel from comment #9)
> Note that isCrossCompilation would return 0 for :
>  - clang (which can even be multi target)
>  - x86_64 multiarch, ie CC="gcc -m32" (in this case "gcc -m32 -dumpmachine"
> would return the wrong value anyway)
> 
> With cmake, it is recommended to use a toolchain file when cross-compiling,
> ie --cmakeargs="-DCMAKE_TOOLCHAIN_FILE=xxxx".
> The toolchain file can then set CMAKE_SYSTEM_PROCESSOR (but
> --system-information mode doesn't accept arguments, so it cannot be tested
> without generating a normal project).

That's right.

What I have committed is not perfect, but is the best thing I could come with. And it will work for the use case I was trying to support (cross-build for mips32el on an amd64 machine with the toolchain generated by buildroot)

If you know about a better way of detecting if we are cross-compiling or detecting the target architecture please submit a patch and put me in the CC list. 

Thanks.

[Loïc Yhuel]

(In reply to Carlos Alberto Lopez Perez from comment #10)> 
> If you know about a better way of detecting if we are cross-compiling or
> detecting the target architecture please submit a patch and put me in the CC
> list. 
I didn't find anything simple which would work in all cases (perhaps creating a cmake project would work, but it would by tricky and IHMO overkill).
In my case, since build-webkit is called from an external build system, it was easier to add a --architecture argument, which bypasses the autodetection (and saves on few seconds on incremental builds by avoiding the cmake --system-information, even when I'm not cross-compiling).

[Carlos Alberto Lopez Perez]

(In reply to Loïc Yhuel from comment #11)
> (In reply to Carlos Alberto Lopez Perez from comment #10)> 
> > If you know about a better way of detecting if we are cross-compiling or
> > detecting the target architecture please submit a patch and put me in the CC
> > list. 
> I didn't find anything simple which would work in all cases (perhaps
> creating a cmake project would work, but it would by tricky and IHMO
> overkill).
> In my case, since build-webkit is called from an external build system, it
> was easier to add a --architecture argument, which bypasses the
> autodetection (and saves on few seconds on incremental builds by avoiding
> the cmake --system-information, even when I'm not cross-compiling).

Adding an --architecture argument is another option, and maybe the most sane one.

It would require some changes in the buildbot configuration. Each bot has defined the architecture name in Tools/BuildSlaveSupport/build.webkit.org-config/config.json -- we could pass that value as an argument to the build-webkit and build-jsc scripts. That way the perl tooling would use the passed value instead of trying to auto-detect it.