Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix static linking when using MinGW-w64 #15167

Merged
merged 4 commits into from
Nov 8, 2024

Conversation

HertzDevil
Copy link
Contributor

@HertzDevil HertzDevil commented Nov 6, 2024

Resolves part of #6170.

  • The MinGW-w64 equivalent for MSVC's libcmt.lib or msvcrt.lib is provided by MinGW-w64's built-in spec files directly (see cc -dumpspecs), so we do not link against it.
  • There cannot be static libraries for the Win32 APIs in MinGW-w64, because that would be proprietary code; all static libraries on MSYS2 link against the C runtimes dynamically, i.e. they behave like /MD in MSVC or CMAKE_MSVC_RUNTIME_LIBRARY=MultiThreadedDLL in CMake. We therefore never link against libucrt.
  • Passing -lucrt explicitly may lead to a crash in the startup code when combined with -static and -msvcrt, depending on the relative link order. In MinGW-w64, -lmsvcrt is already equivalent to -lucrt or -lmsvcrt-os, depending on how it was built; in particular, /ucrt64/bin/libmsvcrt.a is a copy of libucrt.a in MSYS2, but /mingw64/bin/libmsvcrt.a is a copy of libmsvcrt-os.a. Thus we drop -lucrt entirely and rely on the MinGW-w64's build-time configuration to select the appropriate C runtime.
  • -mcrtdll can be used to override the C runtime, and it should be possible to cross-build binaries between the MINGW64 and the UCRT64 environments using this flag. The interpreter now imitates this linker behavior.

@HertzDevil HertzDevil added kind:bug A bug in the code. Does not apply to documentation, specs, etc. topic:stdlib:runtime platform:windows-gnu Windows support based on the MinGW-w64 toolchain + MSYS2 labels Nov 6, 2024
@straight-shoota straight-shoota modified the milestones: 1.14.1, 1.15.0 Nov 6, 2024
@HertzDevil HertzDevil removed this from the 1.15.0 milestone Nov 6, 2024
@straight-shoota straight-shoota added this to the 1.15.0 milestone Nov 6, 2024
@straight-shoota straight-shoota merged commit 6caea6a into crystal-lang:master Nov 8, 2024
69 checks passed
@HertzDevil HertzDevil deleted the bug/mingw-w64-ucrt branch November 8, 2024 11:37
CTC97 pushed a commit to CTC97/crystal that referenced this pull request Nov 9, 2024
* The MinGW-w64 equivalent for MSVC's `libcmt.lib` or `msvcrt.lib` is provided by MinGW-w64's built-in spec files directly (see `cc -dumpspecs`), so we do not link against it.
* There cannot be static libraries for the Win32 APIs in MinGW-w64, because that would be proprietary code; all static libraries on MSYS2 link against the C runtimes dynamically, i.e. they behave like `/MD` in MSVC or `CMAKE_MSVC_RUNTIME_LIBRARY=MultiThreadedDLL` in CMake. We therefore never link against `libucrt`.
* Passing `-lucrt` explicitly may lead to a crash in the startup code when combined with `-static` and `-msvcrt`, depending on the relative link order. In MinGW-w64, [`-lmsvcrt` is already equivalent to `-lucrt` or `-lmsvcrt-os`](https://gcc.gnu.org/onlinedocs/gcc/Cygwin-and-MinGW-Options.html), depending on how it was built; in particular, `/ucrt64/bin/libmsvcrt.a` is a copy of `libucrt.a` in MSYS2, but `/mingw64/bin/libmsvcrt.a` is a copy of `libmsvcrt-os.a`. Thus we drop `-lucrt` entirely and rely on the MinGW-w64's build-time configuration to select the appropriate C runtime.
* `-mcrtdll` can be used to override the C runtime, and it _should_ be possible to cross-build binaries between the MINGW64 and the UCRT64 environments using this flag. The interpreter now imitates this linker behavior.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind:bug A bug in the code. Does not apply to documentation, specs, etc. platform:windows-gnu Windows support based on the MinGW-w64 toolchain + MSYS2 topic:stdlib:runtime
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants