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

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

51 lines
1.2 KiB
Nix
Raw Normal View History

2021-01-15 14:45:37 +00:00
{ lib, stdenv, buildPackages
2019-11-11 03:35:59 +00:00
, newScope, overrideCC, crossLibcStdenv, libcCross
}:
2018-08-06 20:25:25 +00:00
2021-01-15 14:45:37 +00:00
lib.makeScope newScope (self: with self; {
2018-08-06 20:25:25 +00:00
cygwinSetup = callPackage ./cygwin-setup { };
2018-08-06 20:25:25 +00:00
2023-04-23 14:22:01 +00:00
dlfcn = callPackage ./dlfcn { };
w32api = callPackage ./w32api { };
2018-08-06 20:25:25 +00:00
mingwrt = callPackage ./mingwrt { };
mingw_runtime = mingwrt;
2018-08-06 20:25:25 +00:00
mingw_w64 = callPackage ./mingw-w64 {
stdenv = crossLibcStdenv;
};
2018-08-06 20:25:25 +00:00
# FIXME untested with llvmPackages_16 was using llvmPackages_8
2019-11-11 03:35:59 +00:00
crossThreadsStdenv = overrideCC crossLibcStdenv
(if stdenv.hostPlatform.useLLVM or false
then buildPackages.llvmPackages.clangNoLibcxx
gccCrossStageStatic: enable dynamic libraries, rename to gccWithoutTargetLibc This commit allows `gccCrossStageStatic` to build dynamically-linked libraries. Since is no longer restricted to building static libraries its name is no longer appropriate, and this commit also renames it to the more-accurate `gccWithoutTargetLibc`. By default, you can't build a gcc that knows how to create dynamic libraries unless you have already built the targetPlatform libc. Because of this, our gcc cross-compiler is built in two stages: 1. Build a cross-compiler (gccCrossStageStatic) that can build only static libraries. 2. Use gccCrossStageStatic to compile the targetPlatform libc. 3. Use the targetPlatform libc to build a fully-capable cross compiler. You might notice that this pattern looks very similar to what we do with `xgcc` in the stdenv bootstrap. Indeed it is! I would like to work towards getting the existing stdenv bootstrap to handle cross compilers as well. However we don't want to cripple `stdenv.xgcc` by taking away its ability to build dynamic libraries. It turns out that the only thing gcc needs the targetPlatform libc for is to emit a DT_NEEDED for `-lc` into `libgcc.so`. That's it! And since we don't use `gccCrossStageStatic` to build anything other than libc, it's safe to omit the `DT_NEEDED` because that `libgcc` will never be loaded by anything other than `libc`. So `libc` will already be in the process's address space. Other people have noticed this; crosstool-ng has been using this approach for a very long time: https://github.com/crosstool-ng/crosstool-ng/blob/36ad0b17a732aaffe4701d5d8d410d6e3e3abba9/scripts/build/cc/gcc.sh#L638-L640
2023-06-16 21:15:36 +00:00
else buildPackages.gccWithoutTargetLibc.override (old: {
2019-11-11 03:35:59 +00:00
bintools = old.bintools.override {
libc = libcCross;
};
libc = libcCross;
}));
mingw_w64_headers = callPackage ./mingw-w64/headers.nix { };
2018-08-06 20:25:25 +00:00
2019-11-11 03:35:59 +00:00
mingw_w64_pthreads = callPackage ./mingw-w64/pthreads.nix {
stdenv = crossThreadsStdenv;
};
mcfgthreads_pre_gcc_13 = callPackage ./mcfgthreads/pre_gcc_13.nix {
stdenv = crossThreadsStdenv;
};
2019-11-11 03:35:59 +00:00
mcfgthreads = callPackage ./mcfgthreads {
stdenv = crossThreadsStdenv;
};
2018-08-06 20:25:25 +00:00
2022-05-18 12:15:04 +00:00
npiperelay = callPackage ./npiperelay { };
pthreads = callPackage ./pthread-w32 { };
2018-08-06 20:25:25 +00:00
libgnurx = callPackage ./libgnurx { };
})