daytooner daytooner - 2 months ago 14
Linux Question

cross compiling gstreamer fails: x86-64 -> ARMv6 32-bit

I am trying to build a project on an x86_64 (linux)system for an RPi 1. I have a working tool chain - I have built a small program and run it on the RPi ("Hello World").

The project that I am trying to build is gstreamer

In the configure script, I added the appropriate --host=, and it finds all of the right tools and successfully completes. But then, when I make the project,
I get the following errors:

In file included from gsttracerutils.h:30:0,
from gst_private.h:68,
from gst.c:96:
../gst/gstutils.h: In function '__gst_slow_read64_be':
../gst/gstutils.h:111:61: error: left shift count >= width of type [-Werror=shift-count-overflow]
(((guint##__size) (((const guint8 *) (__data))[__idx])) << (__shift))
../gst/gstutils.h:164:36: note: in expansion of macro '_GST_GET'
#define _GST_READ_UINT64_BE(data) (_GST_GET (data, 0, 64, 56) | \
../gst/gstutils.h:184:10: note: in expansion of macro '_GST_READ_UINT64_BE'
return _GST_READ_UINT64_BE (data);

It seems (at least to me) like the compiler complaining about a 64bit type on a 32 bit cpu (which is right).

Is this a problem with the toolchain compiler? Or something else?

I originally built (successfully) gstreamer on the rpi itself. But since that took a very long time, and I need to be able to re-make the app, I wanted to build it on a fast system.

For clarification:
The build toolchain I am using is crosstool-ng.
I ran the configure command as:

./configure --disable-gtk-doc --disable-examples --disable-benchmarks --disable-gtk-doc-html --host=armv6-rpi-linux-gnueabihf

and from the configure log (config.log):

## ----------- ##
## Core tests. ##
## ----------- ##

configure:3217: checking build system type
configure:3231: result: x86_64-unknown-linux-gnu
configure:3251: checking host system type
configure:3264: result: armv6-rpi-linux-gnueabihf
configure:3284: checking target system type
configure:3297: result: armv6-rpi-linux-gnueabihf
configure:3343: checking for a BSD-compatible install
configure:3411: result: /usr/bin/install -c
configure:3422: checking whether build environment is sane
configure:3477: result: yes
configure:3536: checking for armv6-rpi-linux-gnueabihf-strip
configure:3552: found /nas/temp/build/rpi/tc/x-tools/armv6-rpi-linux-gnueabihf/bin/armv6-rpi-linux-gnueabihf-strip
configure:3563: result: armv6-rpi-linux-gnueabihf-strip

this shows the build system is x86_64, the host and the target are armv6(...).

The errors, as shown above, relate to macros that deal with 64 bit data.

I can take this identical project tree, run,, and make on the rpi-1 itself (using the pignus version of gcc tools - pignus is a fedora 23 spin specifically for the rpi-1), and it completely builds successfully. I also built this project on, and for, the x86_64 system, which was also successful.

And, as mentioned at the beginning, I have built a simple program using the same toolchain - the "Hello World" program - and it compiled and linked successfully on the x86_64 system, and then ran successfully on the rpi.

So, again, my question is: could this be a problem/bug with the cross compiler toolchain, or perhaps something in the project source? Any suggestions on where to look, or what to try?




From unpicking those macros, what the compiler is specifically complaining about is that shifting a value of type guint64 left by 56 bits overflows the type, and is thus undefined.

Now, what that says to me is that you're picking up your host machine's glibconfig.h, where guint64 must be a typedef of unsigned long, i.e. a 64 bit type on that machine, but 32 bits once you feed it into the 32-bit ARM compiler. On the Pi itself you probably have an appropriately-configured glibconfig.h where guint64 is a typedef of unsigned long long instead, hence building natively works.

You need to point the build at the Pi's GLib headers and libraries rather than the host machine's (this compilation error is almost certainly just delaying an ultimate failure to link when the cross-linker finds x86 libraries and rejects them). I've no experience with GStreamer myself, so I can't say exactly how to do that, but according to this mailing list post I found, the correct approach would seem to involve overriding PKG_CONFIG_PATH.