FreeBSD doesn't use LLVM's cxxabi implementation, for backwards
compatibility reasons. Software expects the libcxxrt API when
building on FreeBSD. This fixes the build of
pkgsCross.x86_64-freebsd.boost.
Gcc does not allow `-march=` on PowerPC:
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/RS_002f6000-and-PowerPC-Options.html#RS_002f6000-and-PowerPC-Options
Instead, `-mcpu=` should be used to set the minimum instruction set
and `-mtune=` is used to optimize instruction scheduling for a
specific processor. Both flags take the same set of valid values,
which includes `native`.
This commit causes `isGccArchSupported` to return `false` for PowerPC
targets so we never pass an `-march=` flag, since that will always be
rejected by gcc.
Switches that gnatmake needs to pass to gcc must be given as
"-cargs <gcc_switches>" after at least the files to compile (see the
gnatmake docs for all the subtleties). This commit makes that happen,
in a way that triggers rebuilds only for things that actually depend on
GNAT, and not the other compilers contained in GCC.
On darwin clang driver always sets -D_FORTIFY_SOURCE=0 under asan.
This causes -Werror to trip over macro redefinition:
<command line>:1:9: error: '_FORTIFY_SOURCE' macro redefined [-Werror,-Wmacro-redefined]
#define _FORTIFY_SOURCE 2
^
To avoid it let's always explicitly undefine it first before redefining.
There is context here that I needed when resolving an issue in which
libc was added to NIX_CFLAGS_COMPILE before the C++ stdlib that took
me awhile to understand.
It was suggested to me that this context be included as a comment,
since it is not obvious and could help others in the future.
POSIX sh (and `bash`) impose a restriction on environment variable name
format and disallow hypheps in the names. Normally it's not a problem
as nothing usually tries to refer nyphenated names.
One exception is `nix develop` (https://github.com/NixOS/nix/issues/6848):
$ nix develop -f. gcc -L
gcc-wrapper> ...-get-env.sh: line 70: expand-response-params: bad substitution
Note that bash usually uses explicitly created `expandResponseParams`
variant of the same variable.
To work the problem around let's avoid environment variable export and move
it to `passthru` for `cc` (used ina few places) and remove it completely for
`binutils` (does not seem to be used at all).
Noticed this bug when was trying to bootstrap m4 on darwin. That fixes
line 163: no such file or directory error
That does not solve all problems staging has on darwin.
This enables users to make use of clang's multi-platform/target support
without having to go through full cross system setup. This is especially useful
for generating bpf object files, I'm not even usre what would a no-userland
cross compile system tuple even look like to even try going that route.
Fixes#176128
Otherwise, these warnings are emitted:
command-line option '-Wformat=1' is valid for C/C++/ObjC/ObjC++ but not for Fortran
command-line option '-Wformat-security' is valid for C/C++/ObjC/ObjC++ but not for Fortran
'-Werror=' argument '-Werror=format-security' is not valid for Fortran
Fixes part of #27218
Take a "nixSupport" argument that is an attrset of lists to append
to "$out/nix-support/${name}" where name is the name of the
attribute. This attrset is available from the passthru of the
wrapped compiler.
This is an alternative to imperatively issuing flags with
extraBuildCommands and makes it possible to append or filter
flags with an override.
In https://github.com/NixOS/nixpkgs/issues/158042 I noticed order
mismatch as a bootstrap build failure when building x86_64-linux
against glibc-2.35 in nixpkgs (bootstrap libs has glibc-2.27):
expand-response-params> ld: /nix/store/p4s4jf7aq6v6z9iazll1aiqwb34aqxq9-bootstrap-tools/lib/crt1.o: in function `_start':
expand-response-params> /build/glibc-2.27/csu/../sysdeps/x86_64/start.S:101: undefined reference to `__libc_csu_fini'
expand-response-params> ld: /build/glibc-2.27/csu/../sysdeps/x86_64/start.S:102: undefined reference to `__libc_csu_init'
expand-response-params> collect2: error: ld returned 1 exit status
Here crt1.o from glibc-2.27 links against libc.so.6 from glibc-2.35.
This happens because ordering of `-L` (influences `libc.so` lookup) and
`-B` (influences `crt1.o` lookup) flags differs:
expand-response-params> -B/...-bootstrap-tools/lib
expand-response-params> -B/...-glibc-2.35/lib/
...
expand-response-params> -L/...-glibc-2.35/lib
expand-response-params> -L/...-bootstrap-tools/lib
The change makes consistent ordering of `-L`/`-B` and allows getting to
stage4 for `glibc-2.35` target.
So far we've ignored response files in arguments, and did not
check linkType against expanded parameters. This means if
we have `-static` in a @reponse-file, linkType will not be
set to `-static` as we never check against the expanded arguments
from response files.
fixes e.g.:
pkgsMusl.libfsm
pkgsMusl.libiscsi
pkgsMusl.nsjail
pkgsMusl.pv
match strings have whitespace on either side, which wasn't
matching leading/trailing arguments previously
fixes:
pkgsMusl.bulletml
pkgsMusl.proot
pkgsMusl.python3
Debian explains this issue well in the dpkg-buildflags manpage:
-fPIE
Can be linked into any program, but not a shared library (recommended).
-fPIC
Can be linked into any program and shared library.
On projects that build both programs and shared libraries you might need to
make sure that when building the shared libraries -fPIC is always passed last
(so that it overrides any previous -PIE) to compilation flags such as CFLAGS.
(from https://manpages.debian.org/bullseye/dpkg-dev/dpkg-buildflags.1.en.html#hardening)
