When cross-compiling a rust package, all we need is the std library compiled
for the target. This uses the final stage compiler which was built for Build
and then uses that as a stage0 compiler for target std library.
It also copies the rust binary from pkgsBuildBuild so that it find the new
lib/rustlib directory.
We also need to create a cargo wrapper which will use the "new" rust compiler
Also makes sure man pages and doc pages are propagated
Co-authored-by: Alyssa Ross <hi@alyssa.is>
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
Co-authored-by: Rick van Schijndel <Mindavi@users.noreply.github.com>
Cross-compiled binaries currently end up with two different libgcc
outpaths in their closure. This is harmless, but confusing.
The two libgccs are:
- One of them is the "first" targetPlatform libgcc, which is built
by the "first" cross-compiler. This "first libgcc" and "first
compiler" are used to build the targetPlatform glibc.
- Once glibc is built, we *rebuild* the cross-compiler, since gcc
can't enable most of its features unless you give it an
already-compiled targetPlatform glibc. When this "second"
compiler is built, it also builds an extra copy of libgcc.
This commit discards the second, extra libgcc, and instead puts a
reference to the first (correct) libgcc into the "second compiler"
`.passthru.libgcc`, so that anybody expecting `stdenv.cc.cc.libgcc`
to exist will still find it there.
Closes#249680
msvcrt is only one of the libcs in MinGW. We therefore
replace explictly testing for msvcrt with the isMinGW
predicate. This lays the foundation for ucrt64 support.
This change which involves creating multiple outputs for CUDA
redistributable packages.
We use a script to find out, ahead of time, the outputs each redist
package provides. From that, we are able to create multiple outputs for
supported redist packages, allowing users to specify exactly which
components they require.
Beyond the script which finds outputs ahead of time, there is some custom
code involved in making this happen. For example, the way Nixpkgs
typically handles multiple outputs involves making `dev` the default
output when available, and adding `out` to `dev`'s
`propagatedBuildInputs`.
Instead, we make each output independent of the others. If a user wants
only to include the headers found in a redist package, they can do so by
choosing the `dev` output. If they want to include dynamic libraries,
they can do so by specifying the `lib` output, or `static` for static
libraries.
To avoid breakages, we continue to provide the `out` output, which
becomes the union of all other outputs, effectively making the split
outputs opt-in.
