diff options
| author | Adam Joseph <adam@westernsemico.com> | 2024-01-19 20:01:58 -0800 |
|---|---|---|
| committer | Connor Baker <connor.baker@tweag.io> | 2024-03-15 18:18:24 +0000 |
| commit | b81284ec71a1d66aeb11e2ecdcf72fd192d309d8 (patch) | |
| tree | 04f4a3732e5a7b2ffdd23b90fea6787c92d3ba50 /pkgs/development/python-modules/python-mapnik/python-mapnik_std_optional.patch | |
| parent | 655a011eb5f8a35814121bb940d60d828c006e07 (diff) | |
gcc: link $lib/lib -> $lib/$targetConfig correctly and consistently
When native-compiling, gcc will install libraries into:
/nix/store/...-$targetConfig-gcc-$version-lib/lib
When cross-compiling, gcc will install libraries into:
/nix/store/...-$targetConfig-gcc-$version-lib/$targetConfig
When cross-compiling, we intended to create a link from $lib/lib to
$lib/$targetConfig, so that downstream users can always safely
assume that "${lib.getLib stdenv.cc.cc}/lib" is where the gcc
libraries are, regardless of whether `stdenv.cc.cc` is a cross
compiler or a native compiler.
Unfortunately, there were two problems with how we were trying to
create these links:
1. The link would be created only when `enableLibGccOutput==true`
2. The link was being created from the incorrect source
`$lib/lib/lib` instead of `$lib/lib`.
Both of these mistakes are my fault. This commit corrects them by
creating the link using `ln -Ts` (which is more predictable) and by
creating the link from `gcc/common/builder.nix` rather than from
`gcc/common/libgcc.nix`.
Diffstat (limited to 'pkgs/development/python-modules/python-mapnik/python-mapnik_std_optional.patch')
0 files changed, 0 insertions, 0 deletions