3 2

Linux analog of w64devkit

Message ID
DKIM signature
Download raw message
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

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.

Message ID
<CAKF5_TksnnLL1NUhzmOzcYdrtH=ZeEuOA-1oCdATigWS8-08Ag@mail.gmail.com> (view parent)
DKIM signature
Download raw message
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:


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!
Message ID
<20210918214912.p7zollyrzw3bkdon@nullprogram.com> (view parent)
DKIM signature
Download raw message
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
Message ID
<20210922010038.dmruwoo6hvfrnf5p@nullprogram.com> (view parent)
DKIM signature
Download raw message
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.

Reply to thread Export thread (mbox)