Not to be pedantic, but gcc is actually the driver. It is mostly option processing. The C compiler is cc1; the C++ compiler is cc1plus. These are found in the GCC installation directory, which you can find with gcc --print-search-dirs in the “programs” section. The driver’s job is to choose what tool to run (compiler, assembler, or linker) and put all the options together for the tool based on what the user provides combined with the option logic of specs.
You can see what options and environment variables are passed to them when you run gcc -v.
That’s true, I explicitly mention that in future posts, but in this one I didn’t mention that specifically.
EDIT: What I meant by that specific sentence you mention is the code that makes the compilation is inside the GCC codebase, but the other parts are not included and are part of a different project.
I don’t understand the premise of this series. Why not just cross-compile gcc using gcc (e.g. a canadian cross)? And why do they even need to do that in the first place, since RISC-V gcc binaries are widely available?
If we relied in x86 for this, the RISC-V users wouldn’t receive a compiler they can trust, because it’s built on a machine they don’t own, and they can’t verify the how build was done.
The goal of all this project is to provide a fully bootstrappable software distribution, from source.
So it’s only useful for RISC-V users who don’t also own an x86 machine. I guess it’s a theoretically interesting case, and it may change in the future, but at the moment I think there are exactly zero such users.
I encourage you to try to install Guix in a machine, following the full-source-bootstrap process.
There you’ll see everything is designed to work easily.
Forcing your users to install half of the distro in one machine and then move to other may be too much, and it makes the process really hard to audit. Plus, it doesn’t mix with what Guix provides very well. That would be some kind Linux From Scratch tutorial, not a process that is run by the distribution, in a distribution that is designed to provide it with no friction.
Also, you are thinking on an specific kind of user (a person with a home computer), and not in any kind of user. There are contexts where this process is important.
I understand it’s not how Guix is currently setup, but in principle there’s nothing “too much” or “really hard to audit” about cross-compilation. It could work this way: you build riscv-bootstrap package on x86, which produces a single file tarball. You copy a single file to riscv, and bootstrap on riscv from it. Copying a single file is certainly not too much, and the process is as auditable and automated as native compilation except for copying a single file. There is nothing Linux From Scratch about it.
I would like to hear about contexts where you think this process is important. I can’t think of any.
RISC-V is an open architecture, so it also has benefits to provide a fully auditable system, including maybe the hardware too.
We could do cross compilation, of course, it’s just not convenient and you force the users to make manual steps that can be avoided.
So why not write a GCC that runs on x86 and compiles for RISC-V? You can then use that to compile a RISC-V/RISC-V compiler, no bootstrapping with TCC and old GCCs required.
Of course you can do that. If you follow the series you can see how I use cross-compilation for many things, but the goal goes a little bit further than that.
If you want to provide a fully auditable system, involving more than one machine in the process is not ideal. The goal is not to let the Guix maintainers build the software and then distribute it, but make the users able to audit the software their machine receives and installs, and for that we must have the whole process ready for the very machine of the user.
Not to be pedantic, but
gccis actually the driver. It is mostly option processing. The C compiler iscc1; the C++ compiler iscc1plus. These are found in the GCC installation directory, which you can find withgcc --print-search-dirsin the “programs” section. The driver’s job is to choose what tool to run (compiler, assembler, or linker) and put all the options together for the tool based on what the user provides combined with the option logic of specs.You can see what options and environment variables are passed to them when you run
gcc -v.That’s true, I explicitly mention that in future posts, but in this one I didn’t mention that specifically.
EDIT: What I meant by that specific sentence you mention is the code that makes the compilation is inside the GCC codebase, but the other parts are not included and are part of a different project.
I don’t understand the premise of this series. Why not just cross-compile gcc using gcc (e.g. a canadian cross)? And why do they even need to do that in the first place, since RISC-V gcc binaries are widely available?
We want to build a fully bootstrappable ecosystem for RISC-V, from scratch. As we already have for other architectures. Are you familiarized with the effort that Guix community is doing to avoid relying on binary blobs? https://guix.gnu.org/en/blog/2019/guix-reduces-bootstrap-seed-by-50/ https://guix.gnu.org/en/blog/2020/guix-further-reduces-bootstrap-seed-to-25/
If we relied in x86 for this, the RISC-V users wouldn’t receive a compiler they can trust, because it’s built on a machine they don’t own, and they can’t verify the how build was done. The goal of all this project is to provide a fully bootstrappable software distribution, from source.
So it’s only useful for RISC-V users who don’t also own an x86 machine. I guess it’s a theoretically interesting case, and it may change in the future, but at the moment I think there are exactly zero such users.
I encourage you to try to install Guix in a machine, following the full-source-bootstrap process. There you’ll see everything is designed to work easily. Forcing your users to install half of the distro in one machine and then move to other may be too much, and it makes the process really hard to audit. Plus, it doesn’t mix with what Guix provides very well. That would be some kind Linux From Scratch tutorial, not a process that is run by the distribution, in a distribution that is designed to provide it with no friction.
Also, you are thinking on an specific kind of user (a person with a home computer), and not in any kind of user. There are contexts where this process is important.
I understand it’s not how Guix is currently setup, but in principle there’s nothing “too much” or “really hard to audit” about cross-compilation. It could work this way: you build riscv-bootstrap package on x86, which produces a single file tarball. You copy a single file to riscv, and bootstrap on riscv from it. Copying a single file is certainly not too much, and the process is as auditable and automated as native compilation except for copying a single file. There is nothing Linux From Scratch about it.
I would like to hear about contexts where you think this process is important. I can’t think of any.
RISC-V is an open architecture, so it also has benefits to provide a fully auditable system, including maybe the hardware too. We could do cross compilation, of course, it’s just not convenient and you force the users to make manual steps that can be avoided.
You have to provide a binary somewhere. I don’t see the point in providing TCC when you could provide GCC.
The goal is not to provide any binary. See stage-0 project for that.
I am as mystified as you are. Apparently they want to avoid cross-compilation for some reasons, but it is unclear to me why.
They want to show the beginning of the story. At first, you don’t have a GCC that runs on RISC-V and compiles for RISC-V…
So why not write a GCC that runs on x86 and compiles for RISC-V? You can then use that to compile a RISC-V/RISC-V compiler, no bootstrapping with TCC and old GCCs required.
Of course you can do that. If you follow the series you can see how I use cross-compilation for many things, but the goal goes a little bit further than that. If you want to provide a fully auditable system, involving more than one machine in the process is not ideal. The goal is not to let the Guix maintainers build the software and then distribute it, but make the users able to audit the software their machine receives and installs, and for that we must have the whole process ready for the very machine of the user.
See: https://lobste.rs/s/nq1obq/gcc_internals_from_porting_perspective#c_hgee0m