交叉编译gstreamer失败：x86-64 - > ARMv6 32位

Question

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 autogen.sh,configure.sh, 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?

TIA

ken

Answer 1

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 , ie 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.

Answer 2

The problem I am having is exactly that - get the cross compiler to see the target environment and not the build's.

Mounting the Rpi in a subdirectory is also something I'm working on past days, I found a description for an OsX-host, but as I only have Windows-computers I made some workarounds to get the RPi1 booting on an NFS-share of a Trusty-virtual machine instead of the SD-card: https://github.com/rmast/rpi-build-and-boot