All I want is just a collection of #binutils, #GCC, #llvm+#clang, #glibc and #musl that are "free standing" / relocatable, which I can pack into a #squashfs image to carry around to my various development machines.
You'd think that for something as fundamental as compiler infrastructure with over 60 years of knowledge, the whole bootstrapping and bringup process would have been super streamlined, or at least mostly pain free by now.
Yeah, about that. IYKYK
Without looking at how other people approach it, I think the only really viable method to make GCC relocatable is to build it for an installation prefix of the form
/${UNIQUE128BITS/usr
and then just wrap every executable with a loader that hooks open(2) (and equivalents), replacing that unique stem with the absolute path, determined from the wrapper executable's path.
My gut feeling is, that LLVM+clang should be more tolerant of relocation.
@datenwolf You could use mount namespaces with a tmpfs and a bind mount. You can make those without root in a wrapper script. All you need is unshare & mount in the right order. Then you won't have to hook open, nor need a unique prefix.
Take a look at this for how to do such things: https://gist.github.com/Daniel-Abrecht/5cd05da1525abf80ea8e63d63a5fdf82
@DPA Also the whole unshare method completely misses the point, that I *want* to have access to all the other tooling on the host system, and maybe even parts of /usr/include too. Many of my projects come with simple linker stub generating .s sources that declare all the symbols of the runtime .so they depend on.
The goal is not to create an isolated build environment, but a bunch of compilers to build within the environment of the OS they're run in.
@datenwolf You can simply bind mount /usr/, /bin/ and so on, or even /, at the same location as in the host, so you can use those without issue.
The point of doing this is just so you can mount the USB stick at an unknown location, but can have gcc find it's files at a known location. I didn't suggest it for the sake of isolation.
I can't help you much with building gcc, though, that's indeed difficult. You may need to deal with that like you would for a completely different platform.
@DPA I know, but this isn't even the problem I'm confronted ATM.
Right now I'm strugling with something as "simple" as building a "bootstrapping" GCC-10 that goes into /opt/bootstrap/ on a system with a GCC-14 and glibc-2.41. Tons of compilation errors due to language version conflicts. If I first build and install glibc-2.35 to /opt/bootstrap GCC-10 compiles, but fails to link, because somewhere something pulls in the build host's glibc and I end up with a versioned symbol mismatch.