nixpkgs/pkgs/os-specific/windows
Adam Joseph 2affd455a4 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:

  36ad0b17a7/scripts/build/cc/gcc.sh (L638-L640)
2023-07-01 13:12:40 -07:00
..
cygwin-setup
jom
libgnurx
mcfgthreads
mingw-w64
mingwrt
npiperelay
pthread-w32
w32api
wxMSW-2.8
default.nix gccCrossStageStatic: enable dynamic libraries, rename to gccWithoutTargetLibc 2023-07-01 13:12:40 -07:00