search

FreddieChopin / bleeding-edge-toolchain

All-in-one script to build bleeding-edge-toolchain for ARM microcontrollers
71 stars 24 forks source link

Crosscompile the crosscompiler #24

Closed pellepl closed 5 years ago

pellepl commented 5 years ago

First of all, thanks for a great script - works perfectly!

Now, I want to compile a cortex-m4 compiler - on a raspberry. Needless to say, it takes quite some time, and I would love to tinker around with library versions in order to tailor my toolchain. So, I was thinking that I could perhaps cross compile the m4 cross compiler for raspberry on my lightning-fast Linux can. Yeah, sounds fun doesn't it! ;)

Anyhow, to make things easy I got the/a/some raspberry toolchain simply by sudo apt install gcc-arm-linux-gnueabihf which gives me a toolchain with sysroot and everything. Pretty nifty. (I do realize that I need to make the rpi crosscrosstoolchain running on my pc properly with headers according to my rpi system, but that's a later issue)

So, I happily pointed out my rpi compiler and ran the script

$ export CC=/usr/bin/arm-linux-gnueabihf-gcc
$ export CXX=/usr/bin/arm-linux-gnueabihf-g++
$ export LD=/usr/bin/arm-linux-gnueabihf-ld
$ ./build-bleeding-edge-toolchain.sh

Which didn't really play along - GMP complains about configure: error: could not find a working compiler, see config.log for details

Looking in the config.log gives us

int main () { return 0; }
configure:6962: result: no
configure:5858: checking compiler /usr/bin/arm-linux-gnueabihf-gcc -O2 -pedantic -fomit-frame-pointer -pipe 
Test compile: 
configure:5872: /usr/bin/arm-linux-gnueabihf-gcc -O2 -pedantic -fomit-frame-pointer -pipe  conftest.c >&5
configure:5875: $? = 0
configure:5880: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest
/lib/ld-linux-armhf.so.3: No such file or directory
/home/petera/proj/ub-toolchain/bleeding-edge-toolchain-xcomp/sources/gmp-6.1.2/configure: line 5881: ./b.out: No such file or directory
/home/petera/proj/ub-toolchain/bleeding-edge-toolchain-xcomp/sources/gmp-6.1.2/configure: line 5881: ./a.exe: No such file or directory
/home/petera/proj/ub-toolchain/bleeding-edge-toolchain-xcomp/sources/gmp-6.1.2/configure: line 5881: ./a_out.exe: No such file or directory
/home/petera/proj/ub-toolchain/bleeding-edge-toolchain-xcomp/sources/gmp-6.1.2/configure: line 5881: ./conftest: No such file or directory
configure:5883: $? = 127
failed program was:

int main () { return 0; }
configure:6962: result: no, program does not run
configure:7200: error: could not find a working compiler, see config.log for details

where I believe this is the culprit:

configure:5880: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest
/lib/ld-linux-armhf.so.3: No such file or directory

Seems configure is actually trying to run the test binary it just built, which obviously fails as we are on a different target.

So, my question is - how do I get around this? I've been looking through libGMPs sites but cannot really find anything useful. Can you give me a nudge forward?

I tinkered around a bit around here but to no avail.

Of course, would you find that this is an all too odd request, I totally understand if you simply roll your eyes and close this issue directly. :smile:

Cheers!

FreddieChopin commented 5 years ago

Well, the script is done in a way that it first builds the "native" compiler, then tries to cross-compile one for Windows. I guess that the part which does the "native" build has some hard-coded stuff which is not working properly when you try to force it to actually do a cross-compilation. So maybe it would be easier if you would try to modify the part of the script which actually cross-compiles the toolchain for Windows, to just do it for RPi? This would require some more steps than just changing the prefix from the one used by MinGW-W64 to your RPi toolchain, but would be probably doable. There are some differences in the build procedure itself, which are Windows-specific - for example building of libiconv, two versions of gdb, extracting python for windows and so on...

Another approach would be to find the parts which are forcing the build to be "native", which I guess would be at least these:

buildGmp ${buildNative} "" "--build=${hostTriplet} --host=${hostTriplet}"

For a cross build you need to have them different, not the same, for example see this line for Windows:

    buildGmp \
        ${buildFolder} \
        ${bannerPrefix} \
        "--build=${hostTriplet} --host=${triplet}"

Anyway - forcing the "native" part to do the cross-compilation would be hard, at least because the cross-compiler for ARM really needs to be run on the build machine, to compile the target libraries. That's why it would probably be much easier to modify the part which cross-compiles for Windows to do it for RPi.

FreddieChopin commented 5 years ago

BTW:

Needless to say, it takes quite some time

If you want to speed things up, be sure to use --skip-documentation --skip-nano-libraries - this will be ~2x faster than the regular build (and also a bit smaller).

pellepl commented 5 years ago

Thanks for the tip, I'll try the windows->rpi path.

Anyway - forcing the "native" part to do the cross-compilation would be hard, at least because the cross-compiler for ARM really needs to be run on the build machine, to compile the target libraries.

Yeah - I spent some time today realizing what you meant, the hard way. ;)

Again, thanks! I'll give it a go. You may close this issue if you want to - I'll post my findings here if I come up with something useful.

FreddieChopin commented 5 years ago

As you wish (; Let me know if you face some other problems or just ask if something is not clear!

Trass3r commented 5 years ago

If you want to speed things up, be sure to use --skip-documentation --skip-nano-libraries - this will be ~2x faster than the regular build (and also a bit smaller).

Trimming gcc/config/arm/t-rmprofile also helps a lot.