[GTK][WPE] Fix gtkdoc build with "build-webkit --32-bit" on 64-bit hosts
Created attachment 375226 [details] Patch
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"
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. ;)
(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).
> 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?
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....
(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....
(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).
(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.
(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.
Comment on attachment 375226 [details] Patch Clearing flags on attachment: 375226 Committed r248075: <https://trac.webkit.org/changeset/248075>
All reviewed patches have been landed. Closing bug.