freddiechopin / bleeding-edge-toolchain Goto Github PK

I look for the best way to integrate toolchain with CLion IDE (currently 2020.1.1)

Previously I had this configuration:

Anyway IDE was compiling based on gnu-eabi present in the system
Now for stability and compatibility I want assure recomended toolchain

With the standard Ubuntu 19.04 arm-gcc (7.3.1) there's no error. So I'd say it's either a regression in gcc 9 or something is wrong with the way you build the C library.

extern "C"
int _exit(){}
int main() {}
class HardwareSerial3 {
int available() { }
};
void yield() {}

arm-none-eabi-g++ -o main.cpp.o -c -fno-exceptions -felide-constructors -fno-rtti -std=gnu++14 -Wno-error=narrowing -flto -g -ffunction-sections -fdata-sections -mthumb -mcpu=cortex-m4 -nostdlib -O2 main.cpp
arm-none-eabi-g++ -o firmware.elf -g -Wl,--gc-sections,--relax -mthumb -mcpu=cortex-m4 -O2 --specs=nano.specs -Wl,--start-group main.cpp.o -lm -lstdc++ -Wl,--end-group
arm-none-eabi-nm -ClS --radix=d --size-sort firmware.elf

Hello,

Many packages are downloaded in an insecure manner and left unverified. I would appreciate signature verification if it is not too cumbersome to add. Inasmuch as there are users of this script, such an addition would benefit those users.

I may be able to submit a pull request if I have time, but my immediate interest is, hopefully, being able to take the proper configuration this project describes and add that to crossdev, which integrates with portage and has signature verification for downloaded packages.

checking whether to use python... yes
checking for python... /usr/bin/python
CC libctf_la-ctf-open.lo
CC libctf_la-ctf-serialize.lo
checking for python... no
configure: error: python is missing or unusable
CC libctf_la-ctf-sha1.lo
make[1]: *** [Makefile:11124: configure-gdb] Error 1
make[1]: *** Waiting for unfinished jobs....

Does anybody know how to solve that, can anybody help?
Python is installed and previous versions compiled good.
That was the script changed by me.

Current script works as follows

********** Resuming last build
********** Download
********** Extract
---------- Patching gdb-12.1
./build-bleeding-edge-toolchain.sh: 813: pushd: not found
miha@ksonasu:~/allaccess/Gcc-12_t$

how to solve that?

System is Ubuntu 20.

I tested the toolchain, thanks for it!
It even saves 2-3KB compared to my older 8.2 toolchain.
LTO works too but not when adding debug info (worked with the older toolchain). Can you reproduce this?
arm-none-eabi/bin/ld.exe: error: could not unlink output file

Any reason for not enabling the text UI with --enable-tui? :)

We have in our project stumbled on an linking issue when trying to link an locally (Windows) compiled arm target application with an library built on a CI server (linux). The linker error is:
lto1.exe: fatal error: LTO_tags out of range: Range is 0 to 420, value is 0

The linux server compiles the library using the toolchain built with the build-bleeding-edge-toolchain.sh script. On Windows we use the readily available binaries for the bleeding edge gcc.

This issue seems to only persist when the library and the application are compiled on separate machines. Building both the library and the application on the server works without any error. Same on Windows. Presumably this problem is somehow related to the gcc toolchain. Perhaps it might even be some sort of bug in the toolchain..

We spent some time trying to compile the Windows gcc version with the build-bleeding-edge-toolchain.sh script (in mingw64) but there seemed to be quite a lot of issues with the toolchain dependencies. Also trying to cross compile the bleeding edge gcc on MacOS for Windows seemed problematic.

Any suggestions for how to tackle this issue?
Our aim was to compile the bleeding edge gcc with some minor modifications to try and poke at the linking issue.

Thank you for publishing this script. It was a great help in writing my script to build an ARM toolchain.

I have a question. I am trying to use my own toolchain as a replacement for a toolchain supplied by NXP inside their MCUXpresso. It has libcr_newlib_semihost.a, libcr_newlib_nohost.a, and libcr_newlib_none.a. These are not being built by your script. Do you have a clue how to build them?

On Windows (e.g. in WSL) every file is mapped as executable.
Hence lines like

gcc-12.2.0-final build stops with internal compiler error during libgcc build.

With gcc-12.1.0 it works.

I use Makefiles to do some build script, code looks much cleaner than generic shell:
https://github.com/ponyatov/NUC970_NonOS_BSP/tree/GNU/gnu

I'm not sure what this is supposed to do:

• The sed part should use single quotes. Not sure how this ever worked.
• On Linux it's trying to copy dlls from /usr/x86_64-w64-mingw32/bin/ which don't exist of course.
• Will there ever be any runtime dlls required? Shouldn't it produce "static" executables?
• Otoh it does not copy sources/python-2.7.16.amd64/python27.dll which it probably should (?) to produce a self-contained package.

Hi!

this is more a question then an issue but... Did you think about dockerize entire toolchain with IDE and all kind of good stuff?

Hi!
build-bleeding-edge-toolchain.sh faild to build on my system, It seams that on opensuse libraries needs to be located in ${top}/${buildFolder}/${prerequisites}/${<NAME>}/lib insted of ${top}/${buildFolder}/${prerequisites}/${<NAME>}/lib64

the workaround is to add ln -s ${top}/${buildFolder}/${prerequisites}/${<NAME>}/lib64 ${top}/${buildFolder}/${prerequisites}/${<NAME>}/lib for GMP, MPFR, MPC, ISL and EXPAT libraries

I don't provide an diff for this workaround, because I don't know haw would it impact other systems.

1)Do you have a hint how to build for all Cortex-M/R/A and big-endian.
I see you use mrprofile? Can one add additional profiles?

2. I see no way to restart a build. It always starts all over (at least not downloading).
   Did I miss it?

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. 😄

Cheers!