Bug 194147

Summary: [CMake] Build 32bit binaries on Linux/64bit when the --32-bit is passed to build-jsc
Product: WebKit Reporter: Xan Lopez <xan.lopez>
Component: Tools / TestsAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: ap, balducci, commit-queue, dbates, lforschler, mcatanzaro, msaboff, webkit-bug-importer, xan.lopez
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Make --32-bit flag in build-jsc work in Linux/64bit
dbates: review+, dbates: commit-queue-
JSC --32-bit build/intel none

Description Xan Lopez 2019-02-01 01:43:52 PST
The infrastructure to easily build 32bit binaries in a 64bit host is almost there. The following patch fixes a few issues in the build script that allow us to do this transparently.
Comment 1 Xan Lopez 2019-02-01 01:58:18 PST
Created attachment 360851 [details]
Make --32-bit flag in build-jsc work in Linux/64bit
Comment 2 Xan Lopez 2019-03-11 03:46:20 PDT
Adding a few more eyes here with relevant reviews in the file.
Comment 3 Daniel Bates 2019-03-11 06:59:38 PDT
Comment on attachment 360851 [details]
Make --32-bit flag in build-jsc work in Linux/64bit

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

> CMakeLists.txt:96
> +    if (FORCE_32BIT)

Ok as-is. Just a thought, add a comment to explain like what you did in the change log that this is a workaround/hack to support building 32 bit without having to formulate the build  as a crosscompile

> Tools/Scripts/webkitdirs.pm:2264
> +    if ($architecture eq "x86_64"  && shouldBuild32Bit()) {

Looks like an extra space character before the &&

> Tools/Scripts/webkitdirs.pm:2266
> +        # files in debian-based systems, for the others

Debian

> Tools/Scripts/webkitdirs.pm:2269
> +        push @cmakeArgs, '-DFORCE_32BIT=ON -DCMAKE_PREFIX_PATH="/usr" -DCMAKE_LIBRARY_ARCHITECTURE=x86';

Doesn't prefix path affect install path? If so, is that what we want? I don't understand the prefix path part.

> Tools/Scripts/webkitdirs.pm:2270
> +        $ENV{'CFLAGS'} = "-m32" . ($ENV{'CFLAGS'} || "");

More " please and less ' but only on this line and the below. The above line is perfect.

> Tools/Scripts/webkitdirs.pm:2271
> +        $ENV{'CXXFLAGS'} = "-m32" . ($ENV{'CXXFLAGS'} || "");

Ditto.
Comment 4 Xan Lopez 2019-03-11 08:53:01 PDT
(In reply to Daniel Bates from comment #3)
> > +        push @cmakeArgs, '-DFORCE_32BIT=ON -DCMAKE_PREFIX_PATH="/usr" -DCMAKE_LIBRARY_ARCHITECTURE=x86';
> 
> Doesn't prefix path affect install path? If so, is that what we want? I
> don't understand the prefix path part.
> 

Hrm, that would be CMAKE_INSTALL_PREFIX I guess? My understanding is that it is used by the FIND_XXX commands (see https://cmake.org/cmake/help/v3.0/variable/CMAKE_PREFIX_PATH.html). If it is set (it's empty by default) CMake search the .pc files in CMAKE_PREFIX_PATH + "/lib", which is the right path for 32bit .pc files. Otherwise, in a 64bit system, it would use /usr/lib64, etc.

(That does not apply to Debian, that's why I also set another variable as indicated in the comment).
Comment 5 Xan Lopez 2019-03-11 09:17:14 PDT
Created attachment 364259 [details]
JSC --32-bit build/intel

Patch addressing review comments.
Comment 6 Michael Saboff 2019-03-11 11:20:43 PDT
Comment on attachment 364259 [details]
JSC --32-bit build/intel

rs=me
Comment 7 WebKit Commit Bot 2019-03-11 12:11:14 PDT
Comment on attachment 364259 [details]
JSC --32-bit build/intel

Clearing flags on attachment: 364259

Committed r242724: <https://trac.webkit.org/changeset/242724>
Comment 8 WebKit Commit Bot 2019-03-11 12:11:16 PDT
All reviewed patches have been landed.  Closing bug.
Comment 9 Radar WebKit Bug Importer 2019-03-11 12:12:34 PDT
<rdar://problem/48776468>
Comment 10 Michael Catanzaro 2019-03-18 08:45:24 PDT
Please fix this:

Use of uninitialized value $architecture in string eq at /home/mcatanzaro/Projects/WebKit/Tools/Scripts/webkitdirs.pm line 2265.
Comment 11 Alberto Garcia 2021-03-05 08:32:48 PST
*** Bug 191944 has been marked as a duplicate of this bug. ***