Add support for automatically building libgccjit from source

[FractalFir]

Currently, we only distribute a pre-built libgccjit for x86_64, requiring people to build it from scatch on other platforms.

We could add a y.sh gcc command, allowing people to easily clone GCC and build it from source with one command.

Doing so would reduce the barier to entry, and simplify testing on other platforms.

Furthermore, we could integrate this command with cross-ng, allowing people to build cross compilers more easily. We could provide some default configs for common platforms, and allow people to load custom ones.

With a bit more effort(particularly regarding the sysroot), we could even allow people to have multiple builds of libgccjit, stored somewhere like build/libgccjit/config_name. People could then select the libgccjit version they are using(for other commands), like this:

./y.sh rustc --gcc x86_64-linux test.rs # build for x86_64 Linux
./y.sh rustc --gcc dec-alpha-linux test.rs # build for Dec ALPHA Linux
./y.sh rustc --gcc my_config_for_a_very_specific_system # Build with a custom version of `libgccjit`, with some special configs / patches.

This feature could also be useful with Rustup distribution. Providing an easy way to build libgccjit for other platforms would make doing so automatically easier.

[antoyo]

cc @GuillaumeGomez
cc @Kobzol

[antoyo]

With a bit more effort(particularly regarding the sysroot), we could even allow people to have multiple builds of libgccjit, stored somewhere like build/libgccjit/config_name. People could then select the libgccjit version they are using(for other commands), like this:

./y.sh rustc --gcc x86_64-linux test.rs # build for x86_64 Linux
./y.sh rustc --gcc dec-alpha-linux test.rs # build for Dec ALPHA Linux
./y.sh rustc --gcc my_config_for_a_very_specific_system # Build with a custom version of libgccjit, with some special configs / patches.

How is this different than specifying the gcc-path in the config file?

[antoyo]

This feature could also be useful with Rustup distribution. Providing an easy way to build libgccjit for other platforms would make doing so automatically easier.

For this, libgccjit is built in the Rust CI using some other scripts, so I'm not sure that would help.

---

It seems there are different goals for this issue (some for users, some for devs if I understand correctly): could you please write a list or something to have a quick overview of the different goals that you would like to see happen?

From my understanding, different users would want to use cg_gcc differently: I expect many of them would just want to use rustup as it would be the simplest, but I assume we might not have all architectures (and even less having all possibilities of host -> target for cross-compilation). Other users might be want build libgccjit themselves (possibly distro maintainers).

[FractalFir]

With a bit more effort(particularly regarding the sysroot), we could even allow people to have multiple builds of libgccjit, stored somewhere like build/libgccjit/config_name. People could then select the libgccjit version they are using(for other commands), like this:
./y.sh rustc --gcc x86_64-linux test.rs # build for x86_64 Linux
./y.sh rustc --gcc dec-alpha-linux test.rs # build for Dec ALPHA Linux
./y.sh rustc --gcc my_config_for_a_very_specific_system # Build with a custom version of libgccjit, with some special configs / patches.

How is this different than specifying the gcc-path in the config file?

This was meant as a neat addition to the main idea.

Here, I wanted to allow people to more easily manage multiple versions of libgccjit on the same system.

This functions more or less like an equivalent of --target. You specify this flag to override the gcc-path temporarily, and build for a different architecture.

[FractalFir]

The first user I had in mind for this was me. I recently got access to cfarms, and would like to test on a whole lot of architectures. Automating the process will make my life easier. That is the primary motivation for me.

Then, I thought about cross-compilation. There exist crossng configs for specific platforms we might want to target. Adding an way to just select one of them would make the use of people developing on those platforms easier. Let's say you need to run some Rust code on Dec-Alpha. If you could just use a config packaged with cg_gcc to do so, why would not you?

Having a bundle of configs and a way to use them would just make this use case easier.

Additionally, with this we know, for sure, exactly what configs people are using. If everybody brings their own config, we could have a nasty case of bugs only present with those configs. Bugs we can't replicate, because our libgccjit is build slightly differently.

For CI builds, and distro maintainers, we just provided them with a set of ready-to-go configs for building the backend for a wide range of platforms. Even if they don't use the subcommand, that still makes their lives easier. We can also ask them "are you using the default config, or have you made any changes?" - in case of issues.

As a bit of a more out-there idea, I was wondering if this is not something that could be called by rustup. Basically, when somebody wants to install support for dec-alpha, libgccjit would be built on their system, adding suport to all host-target combos(even those that don't have CI builds). I don't know if this is something that should be done, but it could be done.

[Kobzol]

As a bit of a more out-there idea, I was wondering if this is not something that could be called by rustup. Basically, when somebody wants to install support for dec-alpha, libgccjit would be built on their system, adding suport to all host-target combos(even those that don't have CI builds). I don't know if this is something that should be done, but it could be done.

You'd have to ask the Rustup maintainers about this, but I'm pretty sure they wouldn't want to maintain actually building stuff on user's machines :) -Zbuild-std is another use-case for this, but it would complicate rustup quite a lot.

In general, building GCC for more targets is definitely useful, but we already duplicate building GCC and cg_gcc in the main compiler repo and in this repository. I think it would be better if these sorts of things were actually done in the main compiler repo, where we could actually reuse them for CI testing, download-ci-gcc, eventually rustup, etc. But until the development of cg_gcc fully moves into the rustc tree, having the GCC scripts only there would probably not be super helpful for actual cg_gcc development, as most its developers probably work with this repo instead.