https://github.com/NixOS/nixpkgs/pull/328380 updated `gcc11` from
`11.4.0` to `11.5.0` but the darwin patch was not ready then. Let's
update it in hopes that it fixed `darwin` build.
In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
gcc-4.9.4 was released in Aug 3, 2016, 8 years ago. It's a branch that
went out of support years ago. Numerous bugs never get backported to
this version.
Let's remove it.
gcc-4.8.5 was released in June 23, 2015, 9 years ago. It's a branch that
went out of support years ago. Numerous bugs never get backported to
this version.
Let's remove it.
The version of `AvailabilityInternal.h` used in newer SDKs does not work with older versions of GCC that do not support `__has_builtin`. Apply a fixinclude on those versions to allow them to build against the newer version of that header (also used in the source-based SDK after the ld64 update).
Darwin uses absolute path install names, so setting rpaths is unnecessary. This fixes breakage on older versions of GCC that try to set a deployment target that does not support rpaths.
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
6609892a2d68e07da3e5092507a730
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.
- gnat11: make sure to use the gnat-bootstrap gcc in the stdenv; and
- Drop the dual assemblers. x86_64-darwin uses the clang assembler by
default, so it no longer needs the workaround for the GNU assembler.
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`.
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.
THe initial intent of the change was to only affect
`-fmacro-prefix-map=` option.
Due to the bug of `if (maps == macro_prefix_maps)` condition of initial
setting all three of:
static file_prefix_map *macro_prefix_maps; /* -fmacro-prefix-map */
static file_prefix_map *debug_prefix_maps; /* -fdebug-prefix-map */
static file_prefix_map *profile_prefix_maps; /* -fprofile-prefix-map */
matches the comparison and applied the mangling (as long as on options
were passed into those before).
As a result not only (intended) `__FILE__` embedding happened in `.data`
section, but also (unintended) debugging symbols (`-fdebug-prefix-map`)
and profiling data (`-fprofile-prefix-map`) were broken by mangling.
The patch update fixes it by explicitly passing a boolean that controls
the mangling in a single call site relevant to `-fmacro-prefix-map`.
While at it fixed `int / size_t` mismatch that caused build failure on
upcoming `gcc-14`.
Tested as:
- `nix` still has no `nlohmann_json` retention
- `gdb` can now resolve `stdc++` debugging symbols in templates
- `--coverage` has working source file paths
