You would think that something like w64devkit wouldn't be needed on linux, since every distribution makes it easy to access the GNU compiler suite and Unix-style shell tools. In practice, however, if you have to work with multiple devices that are running different distros, and you need a specific compiler version due to using very recent language features / bug fixes, it's surprisingly hard to manage everything, and something portable like w64devkit would be of great use. I was trying to set something like this up, but I was surprised to find that the gcc build appears to be broken with --with-pic --disable-shared --enable-static. Specifically, libstdc++ seems to try to build a shared object anyway, but doesn't actually build it's object files with -fPIC, despite being configured with --with-pic. This issue has been reported by other people in the past and it seems like this has been broken for a while (the workarounds you can find online don't seem to work for the latest gcc either). As the author of w64devkit, I'm curious if you have any insight regarding how to put together a portable, preferably static toolchain for linux. Targeting musl would be even better, but even just having a portable gcc that's set up to link statically would be great. --Harris
I only just recently learned about --with-pic while fixing gfortran for w64devkit, and so far it's worked fine there with only static libraries. GCC's libquadmath wasn't being built as PIC, while the latest Binutils is PIE-only on Windows, making it unlinkable. So, sorry, I don't have any specific insights there. A useful way to approach this is treat it as cross-compilation. Try intentionally targeting a different architecture with your build script to avoid accidentally picking things up from the build host. Perhaps your host's libstdc++ is getting in the way. You have a interesting idea, Harris. Static musl is definitely the way to go in the long run, and I can imagine some uses for this. I've gone partially down this route myself in a few different ways, but not to the point of constructing a "portable" Linux toolchain. I generally use my own custom-built GCC and Clang compilers rather than the system compilers, but I still mostly rely on system libraries like usual. I also keep static builds of certain tools linked with a specific version of musl: https://github.com/skeeto/lean-static-gpg https://github.com/skeeto/lean-static-git None of this is essential. Just useful for testing and experimenting. A problem I've always had with bootstrapping GCC is host contamination. That's even still an issue with w64devkit, but I cover it up by using a bootstrap cross-compiler version identical to the final native compiler. I know Nix has worked out some solution for this — an issue they refer to as "impurity" — but I haven't taken the time to understand it. I thought I might take a crack at this now starting from my w64devkit script and replacing Mingw-w64 with musl, and I quickly got stuck. It's been years since I've built a Linux cross compiler, and I've forgotten how to do it. (A project like w64devkit is great for more permanently capturing things I learn, but that doesn't help much with musl.) If you get this working I'd like to see it!
In case you hadn't seen this yet, by coincidence I just happened to stumble across this today: static cross- and native- musl-based toolchains http://musl.cc/
I spent a couple of hours today trying to get a static toolchain built, but had to put it aside again after repeatedly running into problems. I will definitely let you know if I eventually succeed. I have used musl.cc's compilers in the past with some success, but unfortunately they can be a bit slow to support new gcc releases. I'm in the uncommon position of caring about C and Fortran, but not caring about C++. Fortran has become a very nice language as of the 2018 standard revision, but actual compiler support is still catching up, which is why I always want to grab the latest compiler version whenever one is released. Portability would be nice, since some of my computers are a little old and take a while to build a compiler, but for now the solution of rebuilding the compiler on each box does work. It's just ironic that thanks to w64devkit, this is easier to accomplish on *Windows* than on Linux. --Harris