WIP: Windows cross compilation via LLVM #72366

Ericson2314 · 2019-10-31T13:31:13Z

Motivation for this change

LLVM can do a much better job than GCC via MinGW. In particular, it can do abi-compatable C++ with MSVC, and has more features implemented such proper C++ threads.

I want this because I want Nix to run on Windows, and am continuing @volth's port to make it do so (NixOS/nix#3185). However, I think it's important that we can purely build Nix for all supported platforms, and not ask developers to set up arcane stuff to test their PRs. Therefore I am making this as a self-imposed prerequisite. I need this to do so because Nix uses C++ threads.

Some of this stuff is rather rougher / and more patch heavy than I like my portability initiatives to be, and so I'll hold off trying to port many more packages until the far far future when the requisite tech debt is cleaned up and the portability is maintainable. But I can't do any less than this if I am to build Nix.

The base branch is very intentional, because I will want to merge to 19.09 in addition to master so Nix can use it from there in its CI.

This supports MinGW and Visual Studio headers and libs:

MinGW: { config = "x86_64-pc-mingw32"; useLLVM = true; }
MSVC: { config = "x86_64-pc-windows-msvc"; useLLVM = true; }

Things done

Notify maintainers

cc @angerman

Ericson2314 · 2019-10-31T14:07:12Z

@volth that's fair, and we could run MSVC in wine too, but I think Nix and all its dependencies, like chromium, should be robust enough to build with LLVM.

matthewbauer · 2019-10-31T14:43:04Z

lib/systems/examples.nix

@@ -220,6 +220,16 @@ rec {
    platform = {};
  };

+  windowsLlvm32 = {


We should add this to cross-trunk

matthewbauer · 2019-10-31T14:43:59Z

pkgs/build-support/bintools-wrapper/default.nix


-      for variant in ld.gold ld.bfd ld.lld; do
+      for variant in ld.gold ld.bfd ld.lld${optionalString (targetPlatform.useLLVM or false) " ld64.ldd"}; do


I think this wasn’t actually necessary… let’s leave it out for now (perhaps later we can get macOS llvm cross working)

Yeah it's not necessary; I was just too busy fixing other things to move it out yet.

matthewbauer · 2019-10-31T14:45:21Z

pkgs/build-support/cc-wrapper/default.nix

@@ -339,6 +339,8 @@ stdenv.mkDerivation {
      hardening_unsupported_flags+=" pic"
    '' + optionalString targetPlatform.isMinGW ''
      hardening_unsupported_flags+=" stackprotector"
+    '' + optionalString targetPlatform.isWindows ''


We have so many of these we should provably move these to some attrset (not necessary now)

matthewbauer · 2019-10-31T14:45:46Z

pkgs/build-support/fetchurl/default.nix

@@ -1,4 +1,4 @@
-{ lib, stdenvNoCC, curl }: # Note that `curl' may be `null', in case of the native stdenvNoCC.
+{ lib, buildPackages ? { inherit stdenvNoCC; }, stdenvNoCC, curl }: # Note that `curl' may be `null', in case of the native stdenvNoCC.


This seems awkward?

Indeed it is!

matthewbauer · 2019-10-31T14:47:57Z

pkgs/development/libraries/aws-c-common/default.nix

@@ -11,6 +11,12 @@ stdenv.mkDerivation rec {
    sha256 = "0a7hi4crnc3j1j39qcnd44zqdfwzw1xghcf80marx5vdf1qdzy6p";
  };

+  # It disables it with MSVC, but CMake doesn't realize that clang for windows,
+  # even with gcc-style flags, has the same semantic restrictions.


Is aws manually adding fpic? Perhaps they have a flag to disable it.

They are manually adding it for non-MSVC. CMake should have a better notion of MSVC / destinguish between MSVC the abi (which we are) and MSVC which we aren't since the wrappers just know gcc-style flags.

matthewbauer · 2019-10-31T14:49:37Z

pkgs/os-specific/windows/sdks/default.nix

+{ stdenvNoCC, fetchurl, lib, config, msitools, unzip, static ? false }:
+
+#if !(config.microsoftVisualStudioLicenseAccepted or false)
+if false


Temporary while I get things to work. We should add another line of defense beyond things being broken and not part of the default jobs so @GrahamcOfBorg doesn't do anything with those.

matthewbauer · 2019-10-31T14:50:57Z

Great work!!!

Ericson2314 · 2019-11-03T09:12:18Z

I drafted https://reviews.llvm.org/D69760 which hopefully will fix up some things. Next step might be making a windres-style CLI to llvm-rc, but hopefully that can be put off for a while.

matthewbauer · 2019-11-03T16:58:23Z

pkgs/stdenv/cross/default.nix

@@ -66,7 +66,7 @@ in lib.init bootStages ++ [
             (hostPlatform.isLinux && !buildPlatform.isLinux)
             [ buildPackages.patchelf ]
        ++ lib.optional
-             (let f = p: !p.isx86 || p.libc == "musl" || p.libc == "wasilibc" || p.isiOS; in f hostPlatform && !(f buildPlatform))
+             (let f = p: !p.isx86 || p.libc == "musl" || p.libc == "wasilibc" || p.isiOS || p.isWindows; in f hostPlatform && !(f buildPlatform))


I was wondering if we should just set this to stdenv.hostPlatform != stdenv.buildPlatform. It very rarely hurts anything (there could be some weird custom gnuconfig changes that break) to set it, we mostly just need it for weird platforms though.

Oh! I think I remembered some of the logic was to avoid adding it twice, if native already has it.

We should just do a mass rebuild so everywhere sets it, always.

I don’t think it’s necessary for native. Besides costing a mass rebuild, it also could break some custom scripts.

@matthewbauer We should make a dontAutoreconf for that.

I'd prefer to not have an option for this. Status quo is probably okay. You can always add the hook yourself.

Sorry, I meant dontUpdateAutotoolsGnuConfigScripts, which does exist. I we'll only need to add it in a few places.

aszlig · 2019-11-03T19:12:42Z

@volth: It isn't my realm anymore (and never really has been), since it has been ages since I had anything to do with Windows (luckily :-D), so I can't really say anything on this PR.

Ericson2314 · 2019-11-03T23:45:48Z

Finally zlib builds! But now CMake things don't configure, however (with the switch from lld-link to ld.link). INFO:dialect_default[] it gets running strings on a built binary in both cases. In the lld-link case it doesn't care, presumably because there is a "simulating MSVC" thing and the rules are all different. In the lld.link / clang::toolchains::CrossWindows case it does care, presumably cause it thinks it's more GNU like / MinGW or whatever.

My response is to try going full MinGW, like mstorsjo/llvm-mingw#57, for now, so I am doing that's been done before and which is closer to what we've got.

Summary: Besides the Mingw toolchain, there is also the CrossWindows toolchain, which means GNU-style cli but genuine windows headers + libraries. LLD's MinGW driver is as good a fit as binutil's ld, but there is no easy way to select it when lld was being rewritten to lld-link. This makes lld always be the GNU-style one, consistent with the non-msvc case. It's a small breaking change for Windows, but the only straightforward way. It may seem silly to worry about the gnu-style flags, but it is useful for mixing software designed with MinGW in mind with "real" windows software that needs a MSVC C++ ABI, C++ threads, etc. Testing in conjunction with NixOS/nixpkgs#72366, which might be the first fully automated way to cross compile to Windows. I haven't taught Nixpkgs to wrap clang-cl like it wraps clang, so even for some packages that have separate MSVC and MinGW builds systems (e.g. zlib, opensll), I seem to be having better luck with the MinGW-style builds so am going with that. Reviewers: ruiu, rnk, mstorsjo Subscribers: mstorsjo, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D69760

Mic92 · 2019-11-12T06:24:40Z

pkgs/development/compilers/llvm/8/clang/msvc-lld.patch

+    which might be the first fully automated way to cross compile to
+    Windows.  I haven't taught Nixpkgs to wrap clang-cl like it wraps clang,
+    so even for some packages that have separate MSVC and MinGW builds
+    systems (e.g. zlib, opensll), I seem to be having better luck with the


Suggested change

systems (e.g. zlib, opensll), I seem to be having better luck with the

systems (e.g. zlib, openssl), I seem to be having better luck with the

This is useful if we ever use lld for Darwin instead of cctools.

@est31

[1] Proved incredably useful. Thanks @est31! [1]: https://github.com/est31/msvc-wine-rust/blob/master/dl.sha256

This is needed for building C++ with clang with ld.lld rather than lld-link.

We should look for MSVC- and GNU-style names/exensions.

@mstorsjo

Thanks to @mstorsjo in mstorsjo/llvm-mingw#3 for having the answer.

stale · 2021-10-30T17:09:29Z

I marked this as stale due to inactivity. → More info

cidkidnix · 2023-02-12T07:48:09Z

Heads up here, I'm intending to pick this PR up and get it in a working state against master (or staging-next/staging).
Currently tinkering with it atm, Would love to have llvm-mingw cross-compiling available.

s1341 · 2023-04-24T15:40:53Z

@cidkidnix did you pick this up?

cidkidnix · 2023-04-24T18:00:07Z

@s1341 Yeah I did, been super busy lately, but I had something roughly working in this branch: https://github.com/cidkidnix/nixpkgs/commits/dylang/llvm-mingw. Some logic is weird though. I plan to continue on this sometime soon (hopefully).

s1341 · 2023-04-25T02:54:51Z

@cidkidnix care for some collaboration? I really need this.

Ericson2314 · 2023-04-27T18:03:39Z

@s1341 I think neither of us would mind if you just started picking this up. We can worry about baton passes later.

Also btw check out #228374 (review). It is convenient that UEFI work is also going on concurrently!

Ericson2314 requested review from matthewbauer and volth October 31, 2019 13:31

Ericson2314 requested a review from nbp as a code owner October 31, 2019 13:31

Ericson2314 closed this Oct 31, 2019

Ericson2314 reopened this Oct 31, 2019

Ericson2314 added the 2.status: work-in-progress label Oct 31, 2019

ofborg bot added 6.topic: fetch 6.topic: stdenv Standard environment 2.status: merge conflict labels Oct 31, 2019

Ericson2314 mentioned this pull request Oct 31, 2019

WIP: Windows support -- depends on Meson build system (#3160) NixOS/nix#3185

Closed

matthewbauer reviewed Oct 31, 2019

View reviewed changes

Ericson2314 force-pushed the llvm-windows branch from f42e226 to 2ee3d47 Compare October 31, 2019 15:28

veprbl added 6.topic: cross-compilation Building packages on a different sort platform than than they will be run on 6.topic: windows Running, or buiding, packages on Windows labels Nov 1, 2019

Ericson2314 changed the title ~~WIP: Windows cross compilattation via LLVM~~ WIP: Windows cross compilation via LLVM Nov 3, 2019

matthewbauer reviewed Nov 3, 2019

View reviewed changes

Ericson2314 mentioned this pull request Nov 3, 2019

Collaboration opertunity with Nixpkgs/NixOS mstorsjo/llvm-mingw#57

Open

Ericson2314 force-pushed the llvm-windows branch 2 times, most recently from dd9318a to 7766e03 Compare November 4, 2019 03:52

Ericson2314 force-pushed the llvm-windows branch from 7766e03 to ee38560 Compare November 6, 2019 14:36

Ericson2314 mentioned this pull request Nov 8, 2019

Support for pthreads under mingw-w64. AcademySoftwareFoundation/openexr#591

Closed

Ericson2314 force-pushed the llvm-windows branch from ee38560 to fbc9454 Compare November 12, 2019 03:00

ofborg bot removed the 6.topic: fetch label Nov 12, 2019

Mic92 reviewed Nov 12, 2019

View reviewed changes

ryantm marked this pull request as draft October 23, 2020 03:04

Ericson2314 mentioned this pull request Apr 28, 2021

Do you like Nix? awson/ghc-nw#1

Open

Ericson2314 added 15 commits April 28, 2021 05:14

mingw-w64: Allow parallel buildls

00c4b81

bintools-wrapper: Support ld64.lld

20f546b

This is useful if we ever use lld for Darwin instead of cctools.

requireFile: Support pname and version, too

6f40283

Visual Studio and Windows SDKs: Init at 15

23f1d6d

Visual Studio and Windows SDKs: Hack case normalize

59e2be0

llvm 8 binutils: Add windres wrapper from llvm-mingw

bf31a9a

Windows cross with LLVM: Init

b856ef7

[1] Proved incredably useful. Thanks @est31! [1]: https://github.com/est31/msvc-wine-rust/blob/master/dl.sha256

zlib: Build in various ways for Windows

599ae14

WIP: aws-*: Allow windows builds

5a315d6

WIP: openssl: clang for windows support

c0d734f

lld 8: Support --allow-multiple-definitions in MinGW frontend

b2c3c80

This is needed for building C++ with clang with ld.lld rather than lld-link.

lld 8: Backport commit to fix library lookup

b32d69d

We should look for MSVC- and GNU-style names/exensions.

clang 8: Allow both ld.lld and lld-link to be used for windows builds

d9f72c0

mingw-w64: Patch with master commit so Clang works

3ca58c7

Thanks to @mstorsjo in mstorsjo/llvm-mingw#3 for having the answer.

WIP: libc++ 8: Support Windows

bb6a452

Ericson2314 force-pushed the llvm-windows branch from feb1bb7 to bb6a452 Compare April 28, 2021 05:30

ofborg bot removed the 2.status: merge conflict label Apr 28, 2021

Ericson2314 mentioned this pull request Sep 9, 2021

[CFP] LLVM toolchains in Nixpkgs ClangBuiltLinux/llvm-distributors-conf-2021#20

Open

stale bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Oct 30, 2021

alyssais added the 2.status: merge conflict label Feb 6, 2023

stale bot removed the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Apr 24, 2023

wegank added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Mar 19, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

WIP: Windows cross compilation via LLVM #72366

WIP: Windows cross compilation via LLVM #72366

Ericson2314 commented Oct 31, 2019 •

edited

Ericson2314 commented Oct 31, 2019

matthewbauer Oct 31, 2019

matthewbauer Oct 31, 2019

Ericson2314 Oct 31, 2019

matthewbauer Oct 31, 2019

matthewbauer Oct 31, 2019

Ericson2314 Oct 31, 2019

matthewbauer Oct 31, 2019

Ericson2314 Oct 31, 2019

matthewbauer Oct 31, 2019

Ericson2314 Oct 31, 2019 •

edited

matthewbauer commented Oct 31, 2019

Ericson2314 commented Nov 3, 2019

matthewbauer Nov 3, 2019

Ericson2314 Nov 3, 2019

matthewbauer Nov 4, 2019

Ericson2314 Nov 4, 2019

matthewbauer Nov 4, 2019

Ericson2314 Nov 4, 2019 •

edited

aszlig commented Nov 3, 2019 •

edited

Ericson2314 commented Nov 3, 2019

Mic92 Nov 12, 2019

stale bot commented Oct 30, 2021

cidkidnix commented Feb 12, 2023

s1341 commented Apr 24, 2023

cidkidnix commented Apr 24, 2023

s1341 commented Apr 25, 2023

Ericson2314 commented Apr 27, 2023


		for variant in ld.gold ld.bfd ld.lld; do
		for variant in ld.gold ld.bfd ld.lld${optionalString (targetPlatform.useLLVM or false) " ld64.ldd"}; do

		@@ -1,4 +1,4 @@
		{ lib, stdenvNoCC, curl }: # Note that `curl' may be `null', in case of the native stdenvNoCC.
		{ lib, buildPackages ? { inherit stdenvNoCC; }, stdenvNoCC, curl }: # Note that `curl' may be `null', in case of the native stdenvNoCC.

	systems (e.g. zlib, opensll), I seem to be having better luck with the
	systems (e.g. zlib, openssl), I seem to be having better luck with the

WIP: Windows cross compilation via LLVM #72366

Are you sure you want to change the base?

WIP: Windows cross compilation via LLVM #72366

Conversation

Ericson2314 commented Oct 31, 2019 • edited

Motivation for this change

Things done

Notify maintainers

Ericson2314 commented Oct 31, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Ericson2314 Oct 31, 2019 • edited

Choose a reason for hiding this comment

matthewbauer commented Oct 31, 2019

Ericson2314 commented Nov 3, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Ericson2314 Nov 4, 2019 • edited

Choose a reason for hiding this comment

aszlig commented Nov 3, 2019 • edited

Ericson2314 commented Nov 3, 2019

Choose a reason for hiding this comment

stale bot commented Oct 30, 2021

cidkidnix commented Feb 12, 2023

s1341 commented Apr 24, 2023

cidkidnix commented Apr 24, 2023

s1341 commented Apr 25, 2023

Ericson2314 commented Apr 27, 2023

Ericson2314 commented Oct 31, 2019 •

edited

Ericson2314 Oct 31, 2019 •

edited

Ericson2314 Nov 4, 2019 •

edited

aszlig commented Nov 3, 2019 •

edited