WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
200306
[GTK][WPE] Fix gtkdoc build with "build-webkit --32-bit" on 64-bit hosts
https://bugs.webkit.org/show_bug.cgi?id=200306
Summary
[GTK][WPE] Fix gtkdoc build with "build-webkit --32-bit" on 64-bit hosts
Loïc Yhuel
Reported
2019-07-31 09:03:21 PDT
[GTK][WPE] Fix gtkdoc build with "build-webkit --32-bit" on 64-bit hosts
Attachments
Patch
(1.45 KB, patch)
2019-07-31 09:03 PDT
,
Loïc Yhuel
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Loïc Yhuel
Comment 1
2019-07-31 09:03:57 PDT
Created
attachment 375226
[details]
Patch
Loïc Yhuel
Comment 2
2019-07-31 09:09:29 PDT
I'm now able to build a 32-bit WebKitGtk (without gobject introspection) on a 64-bit Fedora, with : - pkgconf-pkg-config.i686 (probably very similar to setting PKG_CONFIG_LIBDIR if not the same, but this prefixed pkg-config is automatically used for autotools, so it helps in other projects) - many *-devel packages installed manually (rpm considers the dependencies satisfied if either the i686 or the x86_64 package is installed, but that's only enough for multilib-independent headers...) - local fixes to glib2, atk, docbook-style-xsl, and rpmrebuild on gstreamer1-plugins-bad-free-devel to fix conflicts between i686 and x86_64 devel packages - PKG_CONFIG=/usr/bin/i686-redhat-linux-gnu-pkg-config ./Tools/Scripts/build-webkit --32-bit --gtk --cmakeargs="-DENABLE_INTROSPECTION=OFF"
Michael Catanzaro
Comment 3
2019-07-31 09:36:05 PDT
I very nearly set r+ here... but I wonder, should we fix gtk-doc instead? Because it's really not right that -m32 should be required in LDFLAGS, is it? (I'm also sure you know not to use build-webkit for production builds. ;)
Loïc Yhuel
Comment 4
2019-07-31 10:01:26 PDT
(In reply to Michael Catanzaro from
comment #3
)
> I very nearly set r+ here... but I wonder, should we fix gtk-doc instead? > Because it's really not right that -m32 should be required in LDFLAGS, is it?
It uses CFLAGS to build the object files, then only LDFLAGS on link (there is no real standard, there are buildsystems which keep CFLAGS for the link, and others which do not). Also, gtk-doc is disabled when cross-compiling, so multilib is probably borderline.
> (I'm also sure you know not to use build-webkit for production builds. ;)
Well, we still use build-webkit on our downstream target builds (but main compiler flags come from a CMake toolchain file, since it's cross-compiled). It behaves slightly better for development when there are changes, and having two different ways to build WebKit could lead to differences between what the developer sees, and what the integrator gets. This commit is only for host builds, ie when we want to upstream patches or compare behavior between our WPE downstream and WPE/GTK upstream. The 32-bit build matters since our targets are still 32-bit (mostly ARMv7, and sometimes mips32r1 and x86).
Michael Catanzaro
Comment 5
2019-07-31 10:22:30 PDT
> It uses CFLAGS to build the object files, then only LDFLAGS on link (there > is no real standard, there are buildsystems which keep CFLAGS for the link, > and others which do not). > Also, gtk-doc is disabled when cross-compiling, so multilib is probably > borderline.
So -m32 needs to be passed to the linker for the link to succeed?
Michael Catanzaro
Comment 6
2019-07-31 10:24:25 PDT
I'm confused because I only see -m32 in the GCC manpage, not in ld's manpage. That's why I suspect it doesn't belong in LDFLAGS....
Michael Catanzaro
Comment 7
2019-07-31 10:27:13 PDT
(In reply to Loïc Yhuel from
comment #4
)
> > (I'm also sure you know not to use build-webkit for production builds. ;) > Well, we still use build-webkit on our downstream target builds (but main > compiler flags come from a CMake toolchain file, since it's cross-compiled). > It behaves slightly better for development when there are changes, and > having two different ways to build WebKit could lead to differences between > what the developer sees, and what the integrator gets.
Are you manually disabling flags like ENABLE_DEVELOPER_MODE=ON and ENABLE_EXPERIMENTAL_FEATURES=ON? Does build-webkit even work without the testing JHBuild environment? Regardless, I suppose it doesn't matter for this bug....
Loïc Yhuel
Comment 8
2019-07-31 11:01:38 PDT
(In reply to Michael Catanzaro from
comment #5
)
> > It uses CFLAGS to build the object files, then only LDFLAGS on link (there > > is no real standard, there are buildsystems which keep CFLAGS for the link, > > and others which do not). > > Also, gtk-doc is disabled when cross-compiling, so multilib is probably > > borderline. > > So -m32 needs to be passed to the linker for the link to succeed?
It's a compiler flag, but gtk-doc links using gcc (it's rare to call ld directly). On the linker command line, it translates to "-m elf_i386", "-dynamic-linker /lib/ld-linux.so.2", and 32-bit paths for crt*.o and library search paths. For binaries generated by cmake, "-m32" already was in "FLAGS" in build.ninja, and is now in "LINK_FLAGS" too (it uses both). LDFLAGS handling depends on the project : - Most of the time, it's given to the compiler when linking (using CFLAGS for everything isn't an option, since there are flags which would break compilation, or at least generate an "unused argument" warning with clang). - It's sometimes given to the linker. - It's sometimes given to "libtool --mode=link" (which ignore flags it doesn't understand, and has a different handling of "-static" than the compiler (leading to strange problems on projects like binutils which have parts using libtool and parts calling gcc directly).
Loïc Yhuel
Comment 9
2019-07-31 11:17:32 PDT
(In reply to Michael Catanzaro from
comment #7
)
> (In reply to Loïc Yhuel from
comment #4
) > > > (I'm also sure you know not to use build-webkit for production builds. ;) > > Well, we still use build-webkit on our downstream target builds (but main > > compiler flags come from a CMake toolchain file, since it's cross-compiled). > > It behaves slightly better for development when there are changes, and > > having two different ways to build WebKit could lead to differences between > > what the developer sees, and what the integrator gets. > > Are you manually disabling flags like ENABLE_DEVELOPER_MODE=ON and > ENABLE_EXPERIMENTAL_FEATURES=ON? Does build-webkit even work without the > testing JHBuild environment? Regardless, I suppose it doesn't matter for > this bug....
Yes, we disable those flags by default, and only turn them on when needed (our build-webkit command line is in fact quite long, and contains roughtly as many cmake arguments than script ones). I rarely use JHBuild personally : - For our downstream builds, all needed WPE dependencies are built by our buildsystem before WebKit. - For upstream host builds, Fedora has enough devel packages for WPE (now even libwpe and wpebackend-fdo) or GTK. Obviously on Ubuntu 18.04 it's a lot more complex, many flags need to be manually disabled since the packages are too old, or even missing.
Michael Catanzaro
Comment 10
2019-07-31 14:06:18 PDT
(In reply to Loïc Yhuel from
comment #8
)
> It's a compiler flag, but gtk-doc links using gcc (it's rare to call ld > directly). > On the linker command line, it translates to "-m elf_i386", "-dynamic-linker > /lib/ld-linux.so.2", and 32-bit paths for crt*.o and library search paths.
OK, understood.
WebKit Commit Bot
Comment 11
2019-07-31 14:37:05 PDT
Comment on
attachment 375226
[details]
Patch Clearing flags on attachment: 375226 Committed
r248075
: <
https://trac.webkit.org/changeset/248075
>
WebKit Commit Bot
Comment 12
2019-07-31 14:37:07 PDT
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug