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+).
darwin.cctools defaults to `llvm-strip` when the version of LLVM in the
stdenv is 12 or newer. This strip implementation does not support the
`-c` flag required by older versions of GCC. Use the cctools-port
version for compatibility when building older versions of GCC.
The x86_64-darwin build fails with the following symbol errors when
building gencondmd:
Undefined symbols for architecture x86_64:
"_ix86_excess_precision", referenced from:
___cxx_global_var_init.101 in gencondmd.o
"_ix86_fpmath", referenced from:
___cxx_global_var_init.101 in gencondmd.o
"_ix86_isa_flags", referenced from:
___cxx_global_var_init.101 in gencondmd.o
"_ix86_unsafe_math_optimizations", referenced from:
___cxx_global_var_init.101 in gencondmd.o
"_target_flags", referenced from:
___cxx_global_var_init.101 in gencondmd.o
This commit applies a workaround posted to the GCC BugZilla.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92061.
Darwin uses the clang integrated assembler, which does not support
`--gstabs`. While the `configure` script detects whether the assembler
supports it, Darwin passes `--gstabs` unconditionally. This patch is
backported to make the bootstrap only use it when supported.
Older versions of GCC use `-pipe` on Darwin due to compatibility
problems with older cctools assemblers. Darwin now uses the clang
integrated assembler. While it is possible to pipe input into it, the
wrapper used in nixpkgs is not set up for it.
Fixing the wrapper would cause all of Darwin to rebuild, which is not
desirable, so just disable `-pipe` in the bootstrap configuration. The
clang integrated assembler doesn’t have the bug anyway.
The libgcc configure script was middetecting aarch64-darwin and trying
to use a deployment target of 10.5, which is not valid for that
platform. The build was failing because the linker was looking for stubs
that don’t exist (neither as part of the source releases nor as part of
the official SDK from Apple).
Backporting the `config.host` check and `t-darwin-rpath` from GCC 12
allows GCC 11 to build again on aarch64-darwin.
According to Hydra, the last time GCC 4.8 successfully built on Darwin
was October 2014. It is possible to make the first stage build
successfully with clang, but the resulting GCC is not capable of reading
the Darwin SDK headers due to their use of `__can_include`.
It’s been broken for almost a decade, so just disable it.
The rest of our gcc expression prepends "${targetPlatform.config}-"
to paths and binaries if `hostPlatform!=targetPlatform`. The
`libgcc.nix` expression was using
'hostPlatform.config!=targetPlatform.config`, which caused it to
look in the wrong place when moving files. This commit corrects that.
This commit changes the target suffix for the first-stage cross
compiler from `-stage-static` to `-nolibc`, and eliminates the
target suffix from the final-stage cross compiler (previously
`-stage-final`).
Co-authored-by: Artturi <Artturin@artturin.com>
Co-authored-by: John Ericson <git@JohnEricson.me>
It's not just gcc->clang cross compilation that produces different
platforms with equal configs — dynamic->static cross compilation can
have the same result (e.g. pkgsMusl.pkgsStatic). So, remove the check
for LLVM, but keep the check that the configs match.
This fixes pkgsMusl.nix on x86_64-linux, which depends on
pkgsMusl.pkgsStatic.buildPackages.gccWithoutTargetLibc.cc.
Fixes: 926c920c12 ("gcc: tighten condition for inhibit_libc=true")
