Update request: mcfgthreads git → 1.5-ga.2

[panicgh]

• Package name: pkgsCross.mingwW64.windows.mcfgthreads, default.nix
• Latest released version: 1.5-ga.2
• Current version on the unstable channel: git (commit from 2021)
• Current version on the stable/release channel: git, same as unstable
• Checked the nixpkgs pull requests

The upstream repository is a bit strange. Our current source commit is found but does not belong to any branch. Cloning and inspecting the repo, it looks like the upstream rewrote the entire history (including the root commit) in April 2022. Some files that we delete in postUnpack don't exist any more. Simply bumping the version and hash of the source and cleanup postUnpack makes the new package build, but then mingw doesn't build any more (header file not found and indeed the file doesn't exist any more).

The package pname is mcfgthreads (plural) while the upstream repository and the built DLL is mcfgthread (singular).

The update script to download the patches for GCC from another repo does not work either:
https://github.com/NixOS/nixpkgs/blob/49a1f4a0b4b656b5f810959f49d42026f51701e2/pkgs/development/compilers/gcc/update-mcfgthread-patches.sh

It appears as if the patches are now in branch master_gcc-10. But these are identical to the ones we already have (dated 2018), which don't work with the updated mcfgthread.

I tried to update the pkg myself, but it became too complex for me due to all the issues described above.

Notify maintainers

The package has no maintainer (in fact, no meta at all).

@Ericson2314 (last committer to the package)

---

Note for maintainers: Please tag this issue in your PR.

[lhmouse]

The old implementation, which had the DLL name mcfgthread-12.dll did not make use of libtool, which was partly the reason why static linking was not supported. The new implementation uses libtool for version management and by default builds a static library and a shared library at the same time.

That's already breakage, but there's more: Previously, if a TLS key was deleted, all destructors would be called for each TLS value that had been set with that key, mimicking the behavior of FlsFree() ¹. The new implementation tries to be more compliant to standards: Such destructors are only called upon a thread's exit; none of returning from main(), calling exit() and freeing a TLS key shall invoke destructors of TLS keys ².

The mcf thread model, basing on the new implementation, has been merged into GCC 13 ³ and is part of the official release.

Footnotes

1. https://learn.microsoft.com/en-us/windows/win32/api/fibersapi/nf-fibersapi-flsfree ↩

2. https://en.cppreference.com/w/c/thread/tss_create ↩

3. https://github.com/gcc-mirror/gcc/commit/f036d759ecee538555fa8c6b11963e4033732463 ↩

[panicgh]

Thanks for the hint of GCC 13, for which the patch should becomes obsolete. And indeed it is applied only to GCC < 13 and already omitted for GCC 13:

nixpkgs/pkgs/development/compilers/gcc/patches/default.nix

Line 157 in 19b79e7

++ optional (atLeast6 && !atLeast13 && !withoutTargetLibc && targetPlatform.isMinGW && threadsCross.model == "mcf")

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/statically-linked-mingw-binaries/38395/7