Commit Graph

510 Commits

Author SHA1 Message Date
Randy Eckenrode
9a4c598e0a
Merge pull request #317224 from ju1m/NIX_CFLAGS_COMPILE
cc-wrapper: fix -Bprefix to not confuse lib/libc++.so and bin/c++
2024-07-28 20:18:22 -04:00
Julien Moutinho
97c400a0e8 cc-wrapper: fix -Bprefix to not confuse lib/libc++.so and bin/c++
Before this commit, `pkgs/build-support/cc-wrapper/add-flags.sh`
was using `-B@out@/bin` instead of `-B@bintools@/bin`
to force `cc` to use `ld-wrapper.sh` when calling `ld`.
That was confusing `cc` when asked to print
the location of a library precisely named `c++`
because `-B` prefixes are also used by `cc` to find libraries,
see https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html#index-B

Indeed, instead of having `cc --print-file-name c++`
failing to found a `c++` library and just returning the given `c++` string
to let a linker resolve it thereafter,
it was finding that `@out@/bin/c++` executable,
mistaking it for a library and returning its absolute path,
forcing the linker to load an executable as a library.

Before this commit:

```console
$ nix run -f . stdenv.cc -- --print-file-name c++
/nix/store/9bv7dcvmfcjnmg5mnqwqlq2wxfn8d7yi-gcc-wrapper-13.2.0/bin/c++
```

After this commit:

```console
$ nix run -f . stdenv.cc -- --print-file-name c++
c++
```

Fixes https://gitlab.haskell.org/ghc/ghc/-/issues/23138#note_567034
where this behavior was breaking GHC on Darwin.

[Confirmed by @414owen](https://github.com/NixOS/nixpkgs/pull/317224#issuecomment-2171276177):

> This fixed all our haskell builds on Arm64 darwin, which were trying
> to link in clang++...
2024-07-28 20:55:32 +02:00
Robert Scott
48bde3a189 cc-wrapper: add support for pacret hardening flag on aarch64 2024-07-28 19:27:14 +01:00
tomberek
cc7b011fe1
Merge pull request #318034 from ExpidusOS/feat/zig-cc
Add stdenv & CC support for Zig
2024-07-28 14:09:31 -04:00
Emily
8a837af302
Merge pull request #326819 from risicle/ris-shadowstack
cc-wrapper: add support for `shadowstack` hardening flag
2024-07-28 19:07:52 +01:00
Tristan Ross
9f589ea3a0
arocc: init at 0-unstable-06-01 2024-07-27 19:43:41 -07:00
Tristan Ross
e9fb54b256
cc-wrapper: add zig 2024-07-27 19:43:40 -07:00
Tristan Ross
3c6127cf01
cc-wrapper: exclude clang flags when cpp 2024-07-24 20:31:38 -07:00
Robert Scott
b207b6ef74 cc-wrapper: add support for shadowstack hardening flag 2024-07-14 21:25:47 +01:00
Rick van Schijndel
43ce0f9ee0
Merge pull request #318256 from risicle/ris-stack-clash-protection
cc-wrapper: add stack clash protection hardening flag
2024-06-19 19:54:30 +02:00
Alyssa Ross
6f756b4065 clang: don't set machine flags for overridden target
We already did this for -march in 12b0e8ac74 ("clang: don't set
-march for overridden target"), but it should have been done for all
machine flags, for the same reason.

Example bug this fixes:

	nix-shell -E '
	  with import ./. {
	    crossSystem = {
	      system = "powerpc64le-linux";
	      gcc.cpu = "power10";
	    };
	  };
	  clangStdenv.mkDerivation { name = "test"; }
	' --run '$CC -target wasm32-unknown-unknown -c /dev/null'

Which previously failed with:

      clang: error: unsupported option '-mcpu=' for target 'wasm32-unknown-unknown'
2024-06-15 08:02:29 +02:00
Franz Pletz
3db93c351d cc-wrapper: add stack clash protection hardening flag
Most Linux distributions are enabling this these days and it does
protect against real world vulnerabilities as demonstrated by
CVE-2018-16864 and CVE-2018-16865.

Fix #53753.

Information on llvm version support gleaned from
6609892a2d
68e07da3e5
092507a730

Information on gcc version support a lot harder to gather,
but both 32bit and 64bit arm do appear to be supported
based on the test suite.
2024-06-07 20:23:46 +01:00
sternenseemann
7be562d046 wrapCC, wrapBintools: move expand-response-params bootstrapping out
The cc and bintools wrapper contained ad hoc bootstrapping logic for
expand-response-params (which was callPackage-ed in a let binding). This
lead to the strange situation that the bootstrapping logic related to
expand-response-params is split between the wrapper derivations (where
it is duplicated) and the actual stdenv bootstrapping.

To clean this up, the wrappers simply should take expand-response-params
as an ordinary input: They need an adjacent expand-response-params (i.e.
one that runs on their host platform), but don't care about the how.
Providing this is only problematic during stdenv bootstrapping where we
have to pull it from the previous stage at times.
2024-04-18 20:49:13 +02:00
sternenseemann
b2a568906a wrapCC, wrapBintools: use runtimeShell instead of stdenv shell
We don't need to artificially make sure that we can execute the wrapper
scripts on the build platform by using stdenv's shell (which comes from
buildPackages) since our cross infrastructure will get us the wrapper
from buildPackages. The upside of this change is that cross-compiled
wrappers (e.g. pkgsCross.aarch64-multiplatform.gcc) will actually work
when executed!

For bootstrapping this is also not a problem, since we have a long
build->build platform chain so runtimeShell is just as good as
stdenvNoCC.shell. We do fall back to old ways, though, by explicitly
using the bootstrap-tools shell in stage2, so the adjacent bash is only
used from stage4 onwards. This is unnecessary in principle (I'll try
removing this hack in the future), but ensures this change causes zero
rebuilds.
2024-04-18 20:49:13 +02:00
sternenseemann
63d21d1325 wrapCC, wrapBintools: remove unnecessary indexing into platform sets
`targetPlatform` and `hostPlatform` are already in scope, so it is
unnecessary to index into `stdenvNoCC`.
2024-04-15 12:54:29 +02:00
sternenseemann
4aa9e4ecc6 wrapCC, wrapBintools: don't alias stdenvNoCC to stdenv
In delicate code like this, it seems unwise to pass something of as
something it isn't for convenience's (?) sake. It causes a slight
possibility for confusion with `buildPackages.stdenv`. However, it
should be possible to eliminate the need for this in a separate change.
2024-04-15 12:54:25 +02:00
sternenseemann
fde3861f21 wrapCC: check darwin-ness for -mcpu/-march based on targetPlatform
`stdenv.is*` defaults to `hostPlatform` which is technically incorrect
here, since what we are gating concerns the target platform only.

This would be a problem in practice if cross compiling from
x86_64-darwin to aarch64-darwin whilst using gcc which is probably
rare enough.
2024-04-15 12:49:29 +02:00
Tristan Ross
b1ef46706f
llvmPackages_9: remove due to age 2024-04-08 22:39:53 -07:00
Sam
f86158cd9a
Revert "swift: don't pass -march to swiftc"
This reverts commit 8a7841ceef.
2024-04-02 21:42:01 -07:00
annalee
8ead81a60f
Merge remote-tracking branch 'upstream/master' into staging-next 2024-03-17 07:18:11 +00:00
a-n-n-a-l-e-e
8c421f78b2
Merge pull request #296082 from a-n-n-a-l-e-e/dont-pass-march-swift
swift: don't pass -march to swiftc
2024-03-16 19:18:41 -07:00
annalee
8a7841ceef
swift: don't pass -march to swiftc
swiftc uses cc-wrapper which sets the -march flag on some systems which
breaks the build. This change adds a flag, disableMarch, to cc-wrapper
which disables using the -march flag.
https://github.com/NixOS/nixpkgs/issues/295322
2024-03-16 11:02:44 +00:00
github-actions[bot]
5fb2bcd3dd
Merge master into staging-next 2024-03-16 06:00:56 +00:00
Bjørn Forsman
6ff5b79096 Revert "avrlibc: hook up libdir for cc-wrapper"
This reverts commit b2844f89d1.

It broke simavr:

  $ nix-build -A simavr
  [...]
  /nix/store/3k4djrsq23m2yg9ar4h1lkkz1ijv0ghv-avr-binutils-2.41/bin/avr-ld: /nix/store/3rpyzla18mbj690hv7j5dang0kd3c1fq-avr-libc-avr-2.1.0/avr/lib/libc.a(vfprintf_std.o): in function `.L15':
  vfprintf.c:(.text.avr-libc+0xd8): undefined reference to `__mulqi3'
  /nix/store/3k4djrsq23m2yg9ar4h1lkkz1ijv0ghv-avr-binutils-2.41/bin/avr-ld: /nix/store/3rpyzla18mbj690hv7j5dang0kd3c1fq-avr-libc-avr-2.1.0/avr/lib/libc.a(vfprintf_std.o): in function `.L18':
  vfprintf.c:(.text.avr-libc+0xe4): undefined reference to `__mulqi3'
  collect2: error: ld returned 1 exit status
  make[1]: *** [../Makefile.common:161: atmega644_adc_test.axf] Error 1
  make[1]: Leaving directory '/build/source/tests'
  make: *** [Makefile:21: build-tests] Error 2

Fixes #295610.
2024-03-14 20:09:11 +01:00
Philip Taron
e27bcfed1c
Avoid top-level with in pkgs/build-support/cc-wrapper/default.nix (#295213) 2024-03-12 08:34:58 +01:00
a-n-n-a-l-e-e
ce789e7e35
llvmPackages_{12,13,14,15,16,17,git}.{libcxx,libcxxabi}: merge libcxxabi into libcxx (#292043)
- merge libcxxabi into libcxx for LLVM 12, 13, 14, 15, 16, 17, and git.
- remove the link time workaround `-lc++ -lc++abi` from 58 packages as it is no longer required.
- fixes https://github.com/NixOS/nixpkgs/issues/166205
- provides alternative fixes for. https://github.com/NixOS/nixpkgs/issues/269548 https://github.com/NixOS/nix/issues/9640
- pkgsCross.x86_64-freebsd builds work again

This change can be represented in 3 stages
1. merge libcxxabi into libcxx -- files: pkgs/development/compilers/llvm/[12, git]/{libcxx, libcxxabi}
2. update stdenv to account for merge -- files: stdenv.{adapters, cc.wrapper, darwin}
3. remove all references to libcxxabi outside of llvm (about 58 packages modified)

### merging libcxxabi into libcxx
- take the union of the libcxxabi and libcxx cmake flags
- eliminate the libcxx-headers-only package - it was only needed to break libcxx <-> libcxxabi circular dependency
- libcxx.cxxabi is removed. external cxxabi (freebsd) will symlink headers / libs into libcxx.
- darwin will re-export the libcxxabi symbols into libcxx so linking `-lc++` is sufficient.
- linux/freebsd `libc++.so` is a linker script `LINK(libc++.so.1, -lc++abi)` making `-lc++` sufficient.
- libcxx/default.nix [12, 17] are identical except for patches and `LIBCXX_ADDITIONAL_LIBRARIES` (only used in 16+)
- git/libcxx/defaul.nix  does not link with -nostdlib when useLLVM is true so flag is removed. this is not much different than before as libcxxabi used -nostdlib where libcxx did not, so libc was linked in anyway.

### stdenv changes
- darwin bootstrap, remove references to libcxxabi and cxxabi
- cc-wrapper: remove c++ link workaround when libcxx.cxxabi doesn't exist (still exists for LLVM pre 12)
- adapter: update overrideLibcxx to account for a pkgs.stdenv that only has libcxx

### 58 package updates
- remove `NIX_LDFLAGS = "-l${stdenv.cc.libcxx.cxxabi.libName}` as no longer needed
- swift, nodejs_v8 remove libcxxabi references in the clang override

https://github.com/NixOS/nixpkgs/pull/292043
2024-03-11 03:53:37 -07:00
Vladimír Čunát
0e4d8e918e
Merge #291901: clang: don't set -march for overridden target
...into staging-next
2024-03-01 11:32:18 +01:00
Alyssa Ross
12b0e8ac74
clang: don't set -march for overridden target
If -target is explicitly passed to clang, we shouldn't pass our -march
value for the default target, because it probably won't exist for the
target being used.  Up until now, clang has been lenient with this,
but it's a hard error with clang 17, so since gcc.arch is always set
on aarch64, fixing this is a hard requirement for upgrading our
default clang to 17.

Before (with clang 17 on aarch64-linux):

	$ clang -target bpf -c -o /dev/null test.bpf.c
	clang: warning: ignoring '-fstack-protector-strong' option as it is not currently supported for target 'bpf' [-Woption-ignored]
	clang: error: unsupported option '-march=' for target 'bpf'
	clang: warning: argument unused during compilation: '--gcc-toolchain=/nix/store/cngak08nb1yk44gnjipv5rg1ahh1xkax-gcc-13.2.0' [-Wunused-command-line-argument]

After:

	$ clang -target bpf -c -o /dev/null test.bpf.c
	clang: warning: ignoring '-fstack-protector-strong' option as it is not currently supported for target 'bpf' [-Woption-ignored]
	clang: warning: argument unused during compilation: '--gcc-toolchain=/nix/store/cngak08nb1yk44gnjipv5rg1ahh1xkax-gcc-13.2.0' [-Wunused-command-line-argument]
2024-03-01 09:51:49 +01:00
github-actions[bot]
41e7732291
Merge staging-next into staging 2024-02-25 18:01:23 +00:00
Thomas Heijligen
f2a142727c gnatPackages: Add scope for all ada packages
Ada depencencies musst be build with the same gnat version as the
project. Use a namespace as preperation to build with different gnat
versions.

gprbuild and gnatprove are still globaly visable.
2024-02-25 18:19:50 +01:00
Robert Scott
4a91b3e798 cc-wrapper: add trivialautovarinit hardening flag support
this equates to -ftrivial-auto-var-init=pattern

clang has removed support for -ftrivial-auto-var-init=zero and
are unlikely to re-add it, so use -ftrivial-auto-var-init=pattern
on both compilers if only to make behaviour more consistent
between the two.

add to pkgsExtraHardening's defaultHardeningFlags.
2024-02-24 12:00:09 +00:00
Robert Scott
506ec38e7f cc-wrapper, clang: use new mechanism to selectively unsupport zerocallusedregs
this allows a compiler derivation to provide a
hardeningUnsupportedFlagsByTargetPlatform passthru attr
that will be called with the targetPlatform to determine
the unsupported hardening flags for that platform.

we can do this because even though a clang compiler is
multi-target by nature, cc-wrapper effectively fixes the
target platform at wrapping time. otherwise we'd have to
sniff the intended target at runtime, which wouldn't
be fun at all.

the advantage of using a new attribute instead of
allowing hardeningUnsupportedFlags to optionally be a
function is that hardeningUnsupportedFlags retains its
simple overriding pattern for simple cases (i.e.
  `(prev.hardeningUnsupportedFlags or []) ++ [ "foo" ]`
) which will continue to work as long as the bottom-most
function of hardeningUnsupportedFlagsByTargetPlatform
falls back to hardeningUnsupportedFlags.
2024-01-21 11:16:07 +00:00
Robert Scott
40868719b0 cc-wrapper: add zerocallusedregs hardening flag
this uses the value `used-gpr` which seems to be a commonly
chosen value for general use
2024-01-20 13:48:33 +00:00
github-actions[bot]
0cd628f6d5
Merge master into staging-next 2024-01-20 06:01:03 +00:00
Adam Joseph
86c28ee650 cc-wrapper: relocate proprietary-compiler-specific material
PR #275947, which was self-merged without approvals, inserted
functionality specific to a propriteary closed-source compiler
(CUDA) into cc-wrapper.

This commit relocates this CUDA-specific functionality into the
appropritate place: `cuda-modules`.

It is unclear to me exactly what this function is supposed to be
doing; much of it (like the `.kind` attributes) do not appear to be
used *anywhere* in nixpkgs.  Making sure we don't insert unexplained
deadcode like this is one of the important functions of the review
process.
2024-01-20 05:46:57 +00:00
Adam Joseph
d07ab95104 cc-wrapper: revert speculative commentary
This commit deletes speculative comments which were self-merged with
no approvals in PR #275947.

If you think that "The above 'fix' may be incorrect" the correct
response is to submit a PR which removes the 'fix' and get it reviewed.

Likewise, if you think that "For clang it's not necessary" you
should submit a PR which wraps it in `if !isClang`.

`cc-wrapper` is full of too much junk as it is, let's not make
things worse.
2024-01-20 05:46:41 +00:00
Adam Joseph
0c3d9f28c6 cc-wrapper: drop no-longer-necessary hack
The commit prior to this one, "gcc: fix c++ headers when same
triplet cross compiling" causes gcc's c++ headers to be in the same
outpath subdirectory regardless of whether the gcc build is a
host==target or host!=target compiler.

As a result of that change, the hack in cc-wrapper which adapted to
the different paths is no longer needed.  And, in fact, it must be
removed, since if it is left in place builds such as
pkgsCross.aarch64-multiplatform.firefox will fail as shown below.

```
firefox-unwrapped>  0:02.01(B checking the host C compiler works... yes(B(B
firefox-unwrapped>  0:02.01(B checking for the host C++ compiler... /nix/store/1asqji9djmdlapzs70q7jw2j308ry7cn-clang-wrapper-16.0.6/bin/c++(B(B
firefox-unwrapped>  0:02.14(B checking whether the host C++ compiler can be used... yes(B(B
firefox-unwrapped>  0:02.14(B checking the host C++ compiler version... 16.0.6(B(B
firefox-unwrapped>  0:02.21(B checking the host C++ compiler works... yes(B(B
firefox-unwrapped>  0:02.40(B checking for target linker... lld(B(B
firefox-unwrapped>  0:02.51(B checking for host linker... lld(B(B
firefox-unwrapped>  0:02.60(B checking for 64-bit OS... yes(B(B
firefox-unwrapped>  0:02.67(B checking for new enough STL headers from libstdc++...(B(B
firefox-unwrapped>  0:02.67(B DEBUG: <truncated - see config.log for full output>(B(B
firefox-unwrapped>  0:02.67(B DEBUG: |                 #if defined(__GLIBCXX__) && !defined(_GLIBCXX_RELEASE)(B(B
firefox-unwrapped>  0:02.67(B DEBUG: | #  error libstdc++ not new enough(B(B
firefox-unwrapped>  0:02.67(B DEBUG: | #endif(B(B
firefox-unwrapped>  0:02.67(B DEBUG: | #if defined(_GLIBCXX_RELEASE)(B(B
firefox-unwrapped>  0:02.67(B DEBUG: | #  if _GLIBCXX_RELEASE < 8(B(B
firefox-unwrapped>  0:02.67(B DEBUG: | #    error libstdc++ not new enough(B(B
firefox-unwrapped>  0:02.67(B DEBUG: | #  else(B(B
firefox-unwrapped>  0:02.67(B DEBUG: |      (void) 0(B(B
firefox-unwrapped>  0:02.67(B DEBUG: | #  endif(B(B
firefox-unwrapped>  0:02.67(B DEBUG: | #endif(B(B
firefox-unwrapped>  0:02.67(B DEBUG: |                   ;(B(B
firefox-unwrapped>  0:02.67(B DEBUG: |                   return 0;(B(B
firefox-unwrapped>  0:02.67(B DEBUG: |                 }(B(B
firefox-unwrapped>  0:02.67(B DEBUG: Executing: `/nix/store/7v4bi4q334yircaznwm353h1l5i7k98f-aarch64-unknown-linux-gnu-clang-wrapper-16.0.6/bin/aarch64-unknown-linux-gnu-clang++ /build/conftest.qvbo58dv.cpp -c`(B(B
firefox-unwrapped>  0:02.67(B DEBUG: The command returned non-zero exit status 1.(B(B
firefox-unwrapped>  0:02.67(B DEBUG: Its error output was:(B(B
firefox-unwrapped>  0:02.67(B DEBUG: | /build/conftest.qvbo58dv.cpp:1:10: fatal error: 'cstddef' file not found(B(B
firefox-unwrapped>  0:02.67(B DEBUG: | #include <cstddef>(B(B
firefox-unwrapped>  0:02.67(B DEBUG: |          ^~~~~~~~~(B(B
firefox-unwrapped>  0:02.67(B DEBUG: | 1 error generated.(B(B
firefox-unwrapped>  0:02.67(B ERROR: The libstdc++ in use is not new enough.  Please run ./mach bootstrap to update your compiler, or update your system libstdc++ installation.(B(B
firefox-unwrapped> *** Fix above errors and then restart with "./mach build"
error: build of '/nix/store/5in7xkji5hzqkl14ygwq3vxnni54lykk-firefox-unwrapped-aarch64-unknown-linux-gnu-119.0.1.drv' on 'ssh://root@192.168.22.103' failed: builder for '/nix/store/5in7xkji5hzqkl14ygwq3vxnni54lykk-firefox-unwrapped-aarch64-unknown-linux-gnu-119.0.1.drv' failed with exit code 1
error: builder for '/nix/store/5in7xkji5hzqkl14ygwq3vxnni54lykk-firefox-unwrapped-aarch64-unknown-linux-gnu-119.0.1.drv' failed with exit code 1;
```
2024-01-18 09:01:04 +00:00
Someone Serge
8eda4c36a5
cc-wrapper: cxxStdlib: expose solib and package separately 2024-01-12 17:38:00 +00:00
Rahul Butani
290ea23649
cc-wrapper: expose the c++ std library being used
(cherry picked from commit dc6a8f9f7912363577e11520bafa040c0db14359)
2024-01-12 17:38:00 +00:00
Robert Scott
1a5bd697ad mkDerivation, bintools-wrapper: move defaultHardeningFlags determination to bintools-wrapper
this makes it a lot easier to create a modified stdenv with a
different set of defaultHardeningFlags and as a bonus allows us
to inject the correct defaultHardeningFlags into toolchain wrapper
scripts, reducing repetition.

while most hardening flags are arguably more of a compiler thing,
it works better to put them in bintools-wrapper because cc-wrapper
can easily refer to bintools but not vice-versa.

mkDerivation can still easily refer to either when it is constructed.

this also switches fortran-hook.sh to use the same defaults for
NIX_HARDENING_ENABLE as for C. previously NIX_HARDENING_ENABLE
defaults were apparently used to avoid passing problematic flags
to a fortran compiler, but this falls apart as soon as mkDerivation
sets its own NIX_HARDENING_ENABLE - cc.hardeningUnsupportedFlags
is a more appropriate mechanism for this as it actively filters
out flags from being used by the wrapper, so switch to using that
instead.

this is still an imperfect mechanism because it doesn't handle a
compiler which has both langFortran *and* langC very well - applying
the superset of the two's hardeningUnsupportedFlags to either
compiler's invocation. however this is nothing new - cc-wrapper
already poorly handles a langFortran+langC compiler, applying two
setup hooks that have contradictory options.
2023-12-09 16:30:45 +00:00
pennae
b2844f89d1 avrlibc: hook up libdir for cc-wrapper
-B must be set to the root directory of avrlibc, otherwise gcc cannot
locate crt objects for some attiny devices. -L trains as set by
bintools-wrapper are not necessary with -B set correctly because gcc
takes care of that, and likewise we can drop the -B train from
cc-wrapper because the one spec is enough.
2023-12-03 21:44:27 +11:00
Robert Scott
25920d8de2
Merge pull request #253194 from risicle/ris-nix-hardening-enable-fortify3-imply-fortify
cc-wrapper: ensure `NIX_HARDENING_ENABLE` `fortify3` implies `fortify` too
2023-10-23 19:23:02 +01:00
github-actions[bot]
9f5438ccdf
Merge staging-next into staging 2023-10-23 06:01:38 +00:00
Adam Joseph
0b2036cad0 cc-wrapper: fix -mtune= validation, add ARM, add fallbacks
Before this commit, cc-wrapper/default.nix was using
`isGccArchSupported` to validate `-mtune=` values.  This has two
problems:

- On x86, `-mtune=` can take the same values as `-march`, plus two
  additional values `generic` and `intel` which are not valid for
  `-march`.

- On ARM, `-mtune=` does not take the same values as `-march=`;
  instead it takes the same values as `-mcpu`.

This commit fixes these two problems by adding a new
`isGccTuneSupported` function.  For `isx86` this returns `true` for
the two special values and otherwise defers to `isGccArchSupported`.

This commit also adds support for `-mtune=` on Aarch64.

Unfortunately on Aarch64, Clang does not accept as wide a variety of
`-mtune=` values as Gcc does.  In particular, Clang does not tune
for big.LITTLE mixed-model chips like the very popular RK3399, which
is targeted using `-march=cortex-a72.cortex-a53` in gcc.

To address this problem, this commit also adds a function
`findBestTuneApproximation` which can be used to map
clang-unsupported tunings like `cortex-a72.cortex-a53` to
less-precise tunings like `cortex-a53`.

The work which led to this commit arose because we now have
packages, like `crosvm`, which use *both* `clang` *and* `gcc`.
Previously I had been using `overrideAttrs` to set
`NIX_CFLAGS_COMPILE` on a package-by-package basis based on which
compiler that package used.  Since we now have packages which use
*both* compilers, this strategy no longer works.

I briefly considered splitting `NIX_CFLAGS_COMPILE` into
`NIX_CFLAGS_COMPILE_GCC` and `NIX_CFLAGS_COMPILE_CLANG`, but since
`NIX_CFLAGS_COMPILE` is sort of a hack to begin with I figured that
adding the logic to `cc-wrapper` would be preferable.
2023-10-23 01:31:21 +00:00
Andreas Herrmann
13a4690d0d cc-wrapper: Use MacOS compatible mktemp command
The commit 6f2b3ba027 introduced a
`mktemp` invokation that uses the `--tmpdir` flag, which is not
available on MacOS.

This changes the invokation to a portable one based on the following
StackOverflow answer https://stackoverflow.com/a/31397073/841562 .
2023-10-05 10:44:34 +02:00
Robert Scott
4c6fd59fcd cc-wrapper: ensure NIX_HARDENING_ENABLE fortify3 implies fortify too
even if fortify3 is in hardening_unsupported_flags
2023-09-28 21:49:14 +01:00
Artturi
6f27ba80ea
Merge pull request #255488 from natto1784/libcxxabi 2023-09-20 09:12:51 +03:00
Artturi
f36165c2f1
Merge pull request #253116 from pwaller/fix-static-linktype 2023-09-19 11:41:44 +03:00
Amneesh Singh
accafc0ed3
cc-wrapper: add libcxxabi include flag for LLVM
Removed workaround from llvm 16.

Fixes including cxxabi.h on llvm >=15 libcxxStdenv.

```c
int main() {}
```

```
/nix/store/qwnvng0cbyx0bijm654jpmpl0516hfhx-libcxxabi-15.0.7-dev/include/cxxabi.h:20:10: fatal error: '__cxxabi_config.h' file not found
```

Before llvm 15 this used to work because `libcxx` copied the headers
from `cxxabi` to it's own `include`, which was then picked up by the
line above this one

Alternative fix would be to copy all files from `${cxxabi.dev}/include/c++/v1` to `${cxxabi.dev}/include` so the cc-wrapper setup hook would pick them up, but that would depend on in cxxabi being in buildInputs.

Signed-off-by: Amneesh Singh <natto@weirdnatto.in>
2023-09-18 06:43:32 +05:30
Artturi
fa3a4a18c0
Merge pull request #192459 from danielfullmer/fix-cc-wrapper-libdir 2023-09-07 01:58:51 +03:00