Use MinGW-w64 GCC with other threading library

polygon · April 21, 2022, 4:34pm

I hope this problem isn’t too obscure. I’ve recently looked into cross-compiling Windows programs from NixOS and the whole experience has so far been way more pleasant than I initially feared. However, I’ve noticed something a bit strange with the way that MinGW-w64 compilers are build.

When building GCC, you select a thread-library that is used in the backend whenever something like C++11-threads are used. This is done during the configuration step of the compiler itself. In Nixpkgs, we pull in special patches for a MCF thread model and select the MCF-gthreads library by default. Now, I do not want to shit on MCF and I am sure it is solid software, but having this as a default choice seems a bit weird to me. Searching for MCF threads does not yield a lot of results besides the GitHub page of the project itself. So it leaves me wondering why we select this implementation as default instead of, e.g., pthreads or win32 which seems to be the default for most other MinGW based GCC distributions. Actually, default is too weak, since it is not (as far as I can see) switchable without editing Nixpkgs itself.

It seems to be hardcoded into the GCC derivations here:

github.com

NixOS/nixpkgs/blob/c11ee1c598b15a24d18f142f85ee3d438afc39e6/pkgs/development/compilers/gcc/common/configure-flags.nix#L89


      
          ] ++ lib.optionals (crossMingw && targetPlatform.isx86_32) [
            # See Note [Windows Exception Handling]
            "--enable-sjlj-exceptions"
            "--with-dwarf2"
          ] else [
            (if crossDarwin then "--with-sysroot=${lib.getLib libcCross}/share/sysroot"
             else                "--with-headers=${lib.getDev libcCross}${libcCross.incdir or "/include"}")
            "--enable-__cxa_atexit"
            "--enable-long-long"
            "--enable-threads=${if targetPlatform.isUnix then "posix"
                                else if targetPlatform.isWindows then "mcf"
                                else "single"}"
            "--enable-nls"
          ] ++ lib.optionals (targetPlatform.libc == "uclibc" || targetPlatform.libc == "musl") [
            # libsanitizer requires netrom/netrom.h which is not
            # available in uclibc.
            "--disable-libsanitizer"
          ] ++ lib.optionals (targetPlatform.libc == "uclibc") [
            # In uclibc cases, libgomp needs an additional '-ldl'
            # and as I don't know how to pass it, I disable libgomp.
            "--disable-libgomp"

Also, the GCC derivation uses the threadsCross top-level package to install the actual library alongside of GCC. Its definition looks like this:

  threadsCross =
    if stdenv.targetPlatform.isMinGW && !(stdenv.targetPlatform.useLLVM or false)
    then targetPackages.windows.mcfgthreads or windows.mcfgthreads
    else null;

I was wondering if an effort to change this and make it more flexible so that a pthreads or win32 based solution can be chosen would have a chance to be merged.

I am currently seeing three ways on how this could be changed:

Change threadsCross into an attribute set. threadsCross.package then gets to hold the threading package and threadsCross.option becomes the value that is configured for GCC (e.g. mcf, win32, posix)
Add an attribute to all derivations that are valid as threadsCross. Give them a, e.g., config_option field that holds the value mcf, …
Add a check inside configure-flags.nix to see which packet is selected in threadsCross. If it is MCF, make the string mcf. If it is pthreads, make the string posix. If it is something else, make it win32.

Opinions?

Mic92 · November 6, 2022, 5:10pm

I also agree this should be configurable.