Bug 135932 – 2.5.[12]: problem when installing in a multilib environment

• Component: WebKitGTK
• Status: NEW

[gabriele balducci]

w/2.5.1 (and I guess w/2.5.2 too, didn't try yet) I get a problem
installing in a multilib (ABI32/64) environment

The build for ABI32 chokes at the end:

    [ 95%] Generating ../../WebKit2-4.0.gir

    ...

    /usr/bin/ld: skipping incompatible /home/balducci/tmp/install-us-d/webkitgtk-2.4.4.d/webkitgtk-2.5.1/lib/libwebkit2gtk-4.0.so when searching for -lwebkit2gtk-4.0
    /usr/bin/ld: cannot find -lwebkit2gtk-4.0

    ...[a bunch of similar messages for many ABI32 system libs]...

    linking of temporary binary failed: Command '['/usr/bin/gcc', '-o', '/home/balducci/tmp/install-us-d/webkitgtk-2.4.4.d/webkitgtk-2.5.1/Source/WebKit2/tmp-introspectK7AFYo/WebKit2-4.0', '-Wno-deprecated-declarations', '/home/balducci/tmp/install-us-d/webkitgtk-2.4.4.d/webkitgtk-2.5.1/Source/WebKit2/tmp-introspectK7AFYo/WebKit2-4.0.o', '-L.', '-Wl,-rpath=.', '-Wl,--no-as-needed', '-lwebkit2gtk-4.0', '-ljavascriptcoregtk-4.0', '-L/home/balducci/tmp/install-us-d/webkitgtk-2.4.4.d/webkitgtk-2.5.1/lib', '-Wl,-rpath=/home/balducci/tmp/install-us-d/webkitgtk-2.4.4.d/webkitgtk-2.5.1/lib', '-L/opt/stow.d/versions/glib-2.41.2/usr/lib', '-L/opt/stow.d/versions/gtk+-3.13.6/usr/lib', '-L/opt/stow.d/versions/pango-1.36.5/usr/lib', '-L/opt/stow.d/versions/atk-2.13.3/usr/lib', '-L/opt/stow.d/stow/cairo/usr/lib', '-L/usr/Xorg/lib', '-L/opt/stow.d/stow/cairo/usr/lib', '-L/opt/stow.d/versions/gdk-pixbuf-2.31.0/usr/lib', '-L/opt/stow.d/versions/libsoup-2.47.4/usr/lib', '-L/opt/stow.d/versions/glib-2.41.2/usr/lib', '-Wl,--export-dynamic', '-lgmodule-2.0', '-pthread', '-lgtk-3', '-lgdk-3', '-lpangocairo-1.0', '-lpango-1.0', '-latk-1.0', '-lcairo-gobject', '-lfontconfig', '-lfreetype', '-lz', '-lXrender', '-lX11', '-lcairo', '-lgdk_pixbuf-2.0', '-lsoup-2.4', '-lgio-2.0', '-lgobject-2.0', '-lglib-2.0']' returned non-zero exit status 1
    Source/WebKit2/CMakeFiles/WebKit2-4-gir.dir/build.make:57: recipe for target 'WebKit2-4.0.gir' failed

The reason for the failure is that g-ir-scanner is being passed an
incorrect gcc call lacking the necessary -m32 opt (default ABI being
64 bit).

The following hack:

    diff -c ./Source/WebKit2/PlatformGTK.cmake.FIX_GIR_COMPILER ./Source/WebKit2/PlatformGTK.cmake
    *** ./Source/WebKit2/PlatformGTK.cmake.FIX_GIR_COMPILERWed Aug 13 21:32:59 2014
    --- ./Source/WebKit2/PlatformGTK.cmakeWed Aug 13 21:32:59 2014
    ***************
    *** 741,747 ****
          OUTPUT ${CMAKE_BINARY_DIR}/WebKit2-${WEBKITGTK_API_VERSION}.gir
          DEPENDS WebKit2
          DEPENDS ${CMAKE_BINARY_DIR}/JavaScriptCore-${WEBKITGTK_API_VERSION}.gir
    !     COMMAND CC=${CMAKE_C_COMPILER} CFLAGS=-Wno-deprecated-declarations LDFLAGS=
              ${INTROSPECTION_SCANNER}
              --quiet
              --warn-all
    --- 741,747 ----
          OUTPUT ${CMAKE_BINARY_DIR}/WebKit2-${WEBKITGTK_API_VERSION}.gir
          DEPENDS WebKit2
          DEPENDS ${CMAKE_BINARY_DIR}/JavaScriptCore-${WEBKITGTK_API_VERSION}.gir
    !     COMMAND CC=${CMAKE_C_COMPILER} CFLAGS='-m32 -Wno-deprecated-declarations' LDFLAGS=-m32
              ${INTROSPECTION_SCANNER}
              --quiet
              --warn-all
    ***************
    *** 779,785 ****
          OUTPUT ${CMAKE_BINARY_DIR}/WebKit2WebExtension-${WEBKITGTK_API_VERSION}.gir
          DEPENDS ${CMAKE_BINARY_DIR}/JavaScriptCore-${WEBKITGTK_API_VERSION}.gir
          DEPENDS ${CMAKE_BINARY_DIR}/WebKit2-${WEBKITGTK_API_VERSION}.gir
    !     COMMAND CC=${CMAKE_C_COMPILER} CFLAGS=-Wno-deprecated-declarations LDFLAGS=
              ${INTROSPECTION_SCANNER}
              --quiet
              --warn-all
    --- 779,785 ----
          OUTPUT ${CMAKE_BINARY_DIR}/WebKit2WebExtension-${WEBKITGTK_API_VERSION}.gir
          DEPENDS ${CMAKE_BINARY_DIR}/JavaScriptCore-${WEBKITGTK_API_VERSION}.gir
          DEPENDS ${CMAKE_BINARY_DIR}/WebKit2-${WEBKITGTK_API_VERSION}.gir
    !     COMMAND CC=${CMAKE_C_COMPILER} CFLAGS='-m32 -Wno-deprecated-declarations' LDFLAGS=-m32
              ${INTROSPECTION_SCANNER}
              --quiet
              --warn-all


works around the issue for me, allowing to complete successfully the
build.

Of course, the above is just a hack; but it seems to me that the issue
w/ multilib builds is real. Apologies for not speaking cmake and hence
not being able to go deeper.

If that matters, for ABI32 I build with the following cmake defines:

    -DCMAKE_INSTALL_PREFIX=${PREFIX}
    -DCMAKE_INSTALL_LIBDIR=lib
    -DCMAKE_C_COMPILER_ARG1=-m32
    -DCMAKE_CXX_COMPILER_ARG1=-m32
    -DPORT=GTK
    -DCMAKE_BUILD_TYPE=Release
    -DENABLE_CREDENTIAL_STORAGE=OFF
    -DENABLE_GEOLOCATION=OFF

In particular, I have seen that the CMAKE_C[XX]_COMPILER_ARG1 defines
are essential for ABI32 build, but that doesn't prevent failure of the
WebKit2-4.0.gir target anyway.

I guess some fix should go into FindGObjectIntrospection.cmake, but
I'm not in the position to make any useful seggestion

[Alberto Garcia]

I guess that here you would need to use "gcc -m32" as your compiler,
but I don't know how to do something like that with cmake (see bug 130009).

A workaround is to create a wrapper script that calls "gcc -m32" and
use that script as your C compiler. Would that work for you?

[gabriele balducci]

> I guess that here you would need to use "gcc -m32" as your compiler,
> but I don't know how to do something like that with cmake (see bug 130009).

The job of running with the -m32 option switched on is actually done
*mostly* with these two:
 
    -DCMAKE_C_COMPILER_ARG1=-m32
    -DCMAKE_CXX_COMPILER_ARG1=-m32

The problem seems to be that the above cmake vars are not used in
PlatformGTK.cmake

> A workaround is to create a wrapper script that calls "gcc -m32" and
> use that script as your C compiler. Would that work for you?

yes, this is another quite efficient workaround: things work smoothly
for me by sed-ing PlatformGTK.cmake as per my original report above,
but I will keep your suggestion as a good alternative, thanks.

[Alberto Garcia]

(In reply to comment #2)
> The job of running with the -m32 option switched on is actually done
> *mostly* with these two:
>
>     -DCMAKE_C_COMPILER_ARG1=-m32
>     -DCMAKE_CXX_COMPILER_ARG1=-m32

I understand, and in principle it should be enough with using those
two variables in PlatformGTK.cmake. The problem is:

1) what happens if those are empty. Does it still work fine?
2) what happens if you need more than one parameter. I believe those
   would go to a different variable.

I remember having taken a look when I filed bug 130009 and the
solution didn't seem obvious to me, but I also have little experience
with cmake so I probably overlooked something.

[gabriele balducci]

> I understand, and in principle it should be enough with using those
> two variables in PlatformGTK.cmake. The problem is:
> 
> 1) what happens if those are empty. Does it still work fine?

I guess it would still work with no problems, but I'm almost totally
ignorant about cmake

> 2) what happens if you need more than one parameter. I believe those
>    would go to a different variable.

me too.

Overall, building for a multilib system works 99% (using
CMAKE_C_COMPILER_ARG1 and CMAKE_CXX_COMPILER_ARG1 for setting
-m32/-m64). The only issue seems to me this PlatformGTK.cmake: I guess
it shouldn't take too much extending it to support compiling for
ABI32/64 for someone speaking cmake fluently; but, given that
webkit-gtk is a large project, I might be underestimating the
complexity of such job.

...or maybe I'm simply missing some build configuration option which does
what I want (apologies if so)

[Zan Dobersek]

I would recommend setting -m32 via CFLAGS and CXXFLAGS environment variables or CMAKE_C_FLAGS and CMAKE_CXX_FLAGS definitions.

That would make it possible to search for -m32 in CMAKE_C_FLAGS and add it to the introspection scanner's CFLAGS if necessary.


Searching for CMAKE_C_COMPILER_ARG1 and CMAKE_CXX_COMPILER_ARG1 uses over the net shows that those two are frequently used when the compiler is being invoked through ccache, like `ccache gcc/gxx`. That's why I'd rather avoid these two variables entirely.

[Alberto Garcia]

(In reply to comment #5)
> I would recommend setting -m32 via CFLAGS and CXXFLAGS environment
> variables or CMAKE_C_FLAGS and CMAKE_CXX_FLAGS definitions.
>
> That would make it possible to search for -m32 in CMAKE_C_FLAGS and
> add it to the introspection scanner's CFLAGS if necessary.

Looks good to me.

One other alternative is to build everything using a full 32bit
environment inside a chroot, which is what Debian does.

[gabriele balducci]

> I would recommend setting -m32 via CFLAGS and CXXFLAGS environment
> variables or CMAKE_C_FLAGS and CMAKE_CXX_FLAGS definitions.
> 
> That would make it possible to search for -m32 in CMAKE_C_FLAGS and
> add it to the introspection scanner's CFLAGS if necessary.

just tried with:

export CFLAGS    "-m32  $CFLAGS" 
export CXXFLAGS  "-m32  $CXXFLAGS"

and:

-DCMAKE_INSTALL_PREFIX=${PREFIX}
-DCMAKE_INSTALL_LIBDIR=lib$(ABI64Maybe)
-DCMAKE_C_FLAGS=-m32
-DCMAKE_CXX_FLAGS=-m32
-DPORT=GTK
-DCMAKE_BUILD_TYPE=Release
-DENABLE_CREDENTIAL_STORAGE=OFF
-DENABLE_GEOLOCATION=OFF
-DCMAKE_VERBOSE_MAKEFILE=TRUE

but no joy.

Build stops at the same point with the same error.

I think that the problem is in this
Source/WebKit2/PlatformGTK.cmake file, where I find:

----8<----8<----8<----
[...]
add_custom_command(
    OUTPUT ${CMAKE_BINARY_DIR}/WebKit2-${WEBKITGTK_API_VERSION}.gir
    DEPENDS WebKit2
    DEPENDS ${CMAKE_BINARY_DIR}/JavaScriptCore-${WEBKITGTK_API_VERSION}.gir
    COMMAND CC=${CMAKE_C_COMPILER} CFLAGS=-Wno-deprecated-declarations LDFLAGS=
        ${INTROSPECTION_SCANNER}
        --quiet
        --warn-all
        --symbol-prefix=webkit
        --identifier-prefix=WebKit
        --namespace=WebKit2
        --nsversion=${WEBKITGTK_API_VERSION}
        --include=GObject-2.0
        --include=Gtk-3.0
        --include=Soup-2.4
        --include-uninstalled=${CMAKE_BINARY_DIR}/JavaScriptCore-${WEBKITGTK_API_VERSION}.gir
        --library=webkit2gtk-${WEBKITGTK_API_VERSION}
        --library=javascriptcoregtk-${WEBKITGTK_API_VERSION}
        -L${CMAKE_LIBRARY_OUTPUT_DIRECTORY}
        --no-libtool
        --pkg=gobject-2.0
        --pkg=gtk+-3.0
        --pkg=libsoup-2.4
        --pkg-export=webkit2gtk-${WEBKITGTK_API_VERSION}
        --output=${CMAKE_BINARY_DIR}/WebKit2-${WEBKITGTK_API_VERSION}.gir
        --c-include="webkit2/webkit2.h"
        -DBUILDING_WEBKIT
        -DWEBKIT2_COMPILATION
        -I${CMAKE_SOURCE_DIR}/Source
        -I${WEBKIT2_DIR}
        -I${JAVASCRIPTCORE_DIR}/ForwardingHeaders
        -I${DERIVED_SOURCES_DIR}
        -I${DERIVED_SOURCES_WEBKIT2GTK_DIR}
        -I${FORWARDING_HEADERS_WEBKIT2GTK_DIR}
        ${WebKit2GTK_INSTALLED_HEADERS}
        ${WEBKIT2_DIR}/UIProcess/API/gtk/*.cpp
)

[...plus another equal stanza for WebKit2WebExtension-${WEBKITGTK_API_VERSION}.gir]
----8<----8<----8<----

Now: I cannot set CMAKE_C_COMPILER="gcc -m32" (I tried, but it will cause
an almost immediate stop in the build: cmake language related, I
guess); OTOH, both CFLAGS and LDFLAGS are hardcoded, so setting CFLAGS
in the environment won't have any effect.

In my opinion, this Source/WebKit2/PlatformGTK.cmake file should be
modified so that it can catch CFLAGS or LDFLAGS or ... from the
environment; or some other way should be devised to make it support
both ABIs...

But I'm definitely not in the position to be more detailed

> 
> Searching for CMAKE_C_COMPILER_ARG1 and CMAKE_CXX_COMPILER_ARG1 uses
> over the net shows that those two are frequently used when the
> compiler is being invoked through ccache, like `ccache
> gcc/gxx`. That's why I'd rather avoid these two variables entirely.

Thanks for the info: I actually had the impression that I was somewhat misusing
them: my cmake ignorance

[Zan Dobersek]

Extracting -m32 from CMAKE_C(XX)_FLAGS, as proposed in comment #5, still has to be implemented. That's why it still fails, as expected.

I'm glad that using CFLAGS and CXXFLAGS is an option for you, though.

[appzer0]

Created attachment 237409 [details]
webkit-gtk 2.4.4 build log

Build log with invoked commande line, variables, configure final output and error. Fixed temporarily with a CC="gcc" CXX="g++" on native host but multilib/cross-compiling is broken.