gtk-rs / sys

DEPRECATED, each crate has its own sys folder now.
http://gtk-rs.org/
MIT License
31 stars 25 forks source link

Problem with glib-sys when cross-compiling for armv7 #189

Closed ggtrigg closed 3 years ago

ggtrigg commented 3 years ago

I'm attempting to build a gtk-based app for my raspberry-pi and am using cross to cross-compile it for that architecture. Currently the cross-compile is failing and so far my attempts at finding solutions haven't been successful. On the container that cross is using I can confirm that pkg-config is working...

# pkg-config --cflags --libs glib-2.0
-I//usr/include/glib-2.0 -I//usr/lib/arm-linux-gnueabihf/glib-2.0/include -L//usr/lib/arm-linux-gnueabihf -lglib-2.0

yet here is the cross output...

cross_output.txt

Any suggestions/solutions would be greatly appreciated.

(And if it's useful, here's the environment in the container...

# env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
TERM=xterm
CXX_armv7_unknown_linux_gnueabihf=arm-linux-gnueabihf-g++
PKG_CONFIG_SYSROOT_DIR=/
PKG_CONFIG_LIBDIR=/usr/lib/arm-linux-gnueabihf/pkgconfig
CARGO_TARGET_ARMV7_UNKNOWN_LINUX_GNUEABIHF_LINKER=arm-linux-gnueabihf-gcc
container=podman
PKG_CONFIG_PATH=/usr/lib/arm-linux-gnueabihf/pkgconfig:/usr/share/pkgconfig
CC_armv7_unknown_linux_gnueabihf=arm-linux-gnueabihf-gcc
QEMU_LD_PREFIX=/usr/arm-linux-gnueabihf
RUST_TEST_THREADS=1
CARGO_TARGET_ARMV7_UNKNOWN_LINUX_GNUEABIHF_RUNNER=/linux-runner armv7
HOSTNAME=c3f423c15689
HOME=/root
LOGNAME=root
SHLVL=1
PWD=/
OLDPWD=/
_=/usr/bin/env

)

sdroege commented 3 years ago

As the output suggests, you have to configure pkg-config correctly for cross-compilation:

  pkg-config has not been configured to support cross-compilation.

                  Install a sysroot for the target platform and configure it via
                  PKG_CONFIG_SYSROOT_DIR and PKG_CONFIG_PATH, or install a
                  cross-compiling wrapper for pkg-config and set it via
                  PKG_CONFIG environment variable.
ggtrigg commented 3 years ago

That doesn't seem to be a very helpful response. I haven't done anything with pkg-config and it's managed to cross-compile all the other crates. Or am I missing something? (And the pkc-config output I provided shows that it's picking up the arm-linux-gnueabihf paths for include files & libraries.)

sdroege commented 3 years ago

The error in question comes from https://github.com/rust-lang/pkg-config-rs/blob/54325785816695df031cef3b26b6a9a203bbc01b/src/lib.rs#L316 . You'll have to check the documentation of that crate and generally the pkg-config documentation for how to set up things properly, this has nothing to do with glib-sys. It also seems curious that you have set up PKG_CONFIG_SYSROOT_DIR=/, usually the sysroot for cross-compilation is a directory somewhere else.

Maybe also this blog post will help you.

ggtrigg commented 3 years ago

Sigh. I have been following that blog post and my dockerfile is almost exactly the same as theirs (just exchanging the libgstreamer dev package with gtk dev packages). I have also tried a myriad of different environment variables, including anything that should be preventing the CrossCompilation error but to no avail. And the fact that when I connect to the container and run pkg-config with it returning the correct paths for the target environment is causing more confusion. Sounds like I'd better start a conversation on the pkg-config-rs crate page then.

sdroege commented 3 years ago

Yeah that would be a better place. But also I'm not sure why target_supported() returns false in that linked code for you. It should go into the None case and then PKG_CONFIG_SYSROOT_DIR is set so it should return true.

ggtrigg commented 3 years ago

For completion here, it seems like cross isn't doing everything it's supposed to be doing (& I'm not really sure what that is). If I manually run the container with the appropriate host directories mounted and run (in the container) crate build --target armv7-unknown-linux-gnueabihf and with PKG_CONFIG_ALLOW_CROSS=1 then the build is successful and the binary runs nicely on the Pi. Thanks for taking the time to engage and provide pointers.