Add gccgo build for toolchain.

[Arielfoever]

No description provided.

[cmuellner]

Thanks for the PR!

This opens the question of what to do with other questions (Rust, Ada, etc.). Eventually, we might end up enabling all languages and increasing the default build time, which is something we don't want.

A solution is to have a configure flag that allows the setting of the enabled languages.
C/C++/Fortran will be the default (as we have it now), but one can override this via --enable-languages=....
We will then forward the languages to GCC's configure script (in stamps/build-gcc-linux-stage2).
Of course, such a feature also needs a bit of documentation in the README.

We already have similar features like with-abi, with-arch, with-tune, and with-isa-spec.

Would you be interested in implementing such a mechanism?

[TommyMurphyTM1234]

Do additional languages need additional test suite support or does that get enabled automatically?

Also, I always wondered, why is the default language selection (for the Linux toolchains) C/C++/Fortran rather than maybe just C/C++ which I presume would cover the vast majority of RISC-V development scenarios? Is it because C/C++/Fortran is the default selection for upstream GCC?

[cmuellner]

Do additional languages need additional test suite support or does that get enabled automatically?

Yes, the tests will be enabled automatically.

Also, I always wondered, why is the default language selection (for the Linux toolchains) C/C++/Fortran rather than maybe just C/C++ which I presume would cover the vast majority of RISC-V development scenarios? Is it because C/C++/Fortran is the default selection for upstream GCC?

Short answer: historical reasons.
My guess is, that running benchmarks was an important use-case (e.g. SPEC CPU), where C,C++,Fortran is sufficient. More would just increase the build time.

[TommyMurphyTM1234]

Ok, thanks @cmuellner.

[aswaterman]

For the record, @cmuellner's guess is right; I enabled Fortran by default a long time ago to build SPEC benchmarks.

[TommyMurphyTM1234]

For the record, @cmuellner's guess is right; I enabled Fortran by default a long time ago to build SPEC benchmarks.

Thanks @aswaterman.

[Arielfoever]

Oh hi guys. I'd love to mention you that when you choose make musl, gccgo won't work until you cross build a RISC-V Version kaniini/libucontext and install to prefix/sysroot.

Then use gccgo 1.go -o 1.out -lucontext it will work fine.

I thought this problem is caused by Bug 113143 - Remove usage of ucontext.h .

[TommyMurphyTM1234]

Oh hi guys. I'd love to mention you that when you choose make musl, gccgo won't work until you cross build a RISC-V Version kaniini/libucontext and install to prefix/sysroot.

Can you clarify the exact commands required to do this? I presume it's something like:

# Add RISC-V Linux GCC toolchain to PATH?
git clone https://github.com/kaniini/libucontext
cd libucontext
CC=? make ARCH=? DESTDIR=? install

[Arielfoever]

Oh hi guys. I'd love to mention you that when you choose make musl, gccgo won't work until you cross build a RISC-V Version kaniini/libucontext and install to prefix/sysroot.

Can you clarify the exact commands required to do this? I presume it's something like:

# Add RISC-V Linux GCC toolchain to PATH?
git clone https://github.com/kaniini/libucontext
cd libucontext
CC=? make ARCH=? DESTDIR=? install

make CC='/home/ariel/riscv64musl/bin/riscv64-unknown-linux-musl-gcc' CXX='/home/ariel/riscv64musl/bin/riscv64-unknown-linux-musl-g++' LD='/home/ariel/riscv64musl/bin/riscv64-unknown-linux-musl-ld' AR='/home/ariel/riscv64musl/bin/riscv64-unknown-linux-musl-ar' ARCH=riscv64 DESTDIR='/home/ariel/riscv64musl/sysroot' install

[TommyMurphyTM1234]

Thanks @ArielHeleneto. I guess that if this PR is eventually merged (having added the configuration option suggested by @cmuellner earlier perhaps?) then this info should probably go in the README.

[Arielfoever]

Thanks @ArielHeleneto. I guess that if this PR is eventually merged (having added the configuration option suggested by @cmuellner earlier perhaps?) then this info should probably go in the README.

Agreed but thinking what should I write in README.

I thought adding an option is a better choice as @cmuellner says.

[TommyMurphyTM1234]

I thought adding an option is a better choice as @cmuellner says.

I agree - having the option to build gccgo and not doing it by default sounds like the right way to go.

Agreed but thinking what should I write in README.

Depends on how the option is implemented, what a user needs to do to use it, if there are any additional build prerequisites, if the libucontext stuff for the Musl build needs to be mentioned, if there are any limitations (e.g. I presume that it will only work for a Linux toolchain and not for bare-metal?), etc.

[Arielfoever]

Hi, I did #1559 in response of your suggestion. I think we can now close this Pull request.

Thanks for the PR!

This opens the question of what to do with other questions (Rust, Ada, etc.). Eventually, we might end up enabling all languages and increasing the default build time, which is something we don't want.

A solution is to have a configure flag that allows the setting of the enabled languages. C/C++/Fortran will be the default (as we have it now), but one can override this via --enable-languages=.... We will then forward the languages to GCC's configure script (in stamps/build-gcc-linux-stage2). Of course, such a feature also needs a bit of documentation in the README.

We already have similar features like with-abi, with-arch, with-tune, and with-isa-spec.

Would you be interested in implementing such a mechanism?

[cmuellner]

Closing in favor or #1559.