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
When build platform and host platform differ, but have the same
triple, the code in nixpkgs will consider it a cross compilation,
but gcc won't. This will lead some derivations to look for c++
headers in the wrong place. To solve this always output the headers
in the non-cross location, like we do for the other gcc headers
already.
the mangling done by mangle-NIX_STORE-in-__FILE__.patch also applies to
source paths embedded in debug symbols. When putting a breakpoint in a
template instanciation from another lib, the path that gdb looks for is
therefore mangled (/nix/store/eeeeeee;...-the-lib-dev/include/foo.h)
This severely degrades the debugging experience. To alleviate that, it's
possible to make the mangling reversible: a debuginfod server can then
reverse the mangling. I plan to implement that in nixseparatedebuginfod.
The reversible mangling that was chosen in making the hash of the store
path uppercase.
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.
Fixed conflict in pkgs/applications/graphics/krita/
krita: 5.1.5 -> 5.2.0
7a40fdc288
, and
treewide: use kde mirror everywhere, don't use pname in download urls
aa15f5066d
Building a cross-compiler fails due to register storage class specifier
errors when building with clang 16 due to its defaulting to C++17.
Downgrading the error allows the older cross-compilers to build.
Using flat namespaces causes libstdc++ to link CoreFoundation, but
that fails after #265102. Since CoreFoundation is not actually needed,
disable flat namespaces to avoid linking it unnecessarily.
Disabling flat namespaces matches the behavior of newer versions of
libstdc++ (GCC 7+) when building for newer Darwin hosts (10.5+).
