[Webkit-unassigned] [Bug 200306] [GTK][WPE] Fix gtkdoc build with "build-webkit --32-bit" on 64-bit hosts

[bugzilla-daemon at webkit.org]

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

--- Comment #8 from Loïc Yhuel <loic.yhuel at softathome.com> ---
(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).

-- 
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/20190731/b6145f50/attachment-0001.html>