Commit Graph

344 Commits

Author SHA1 Message Date
Sergei Trofimovich
649ebfbed6 cc-wrapper: change cflags order from cc/crt1/libc to crt1/libc/cc
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.
2022-02-20 10:45:45 +00:00
Moritz Angermann
14996789a1
Check link type based on expanded parameters
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.
2022-01-01 20:30:56 +08:00
r-burns
16728283c3
Merge pull request #135619 from r-burns/fpie-musl-fixes
[staging] {cc,binutils}-wrapper: fixes for PIE hardening
2021-09-23 17:55:08 -07:00
Ryan Burns
37d089c1af {cc,binutils}-wrapper: match leading/trailing arguments
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
2021-09-20 17:24:04 -07:00
Ryan Burns
bd8258a389 cc-wrapper: ensure PIE flags precede PIC flags
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)
2021-09-20 11:03:42 -07:00
John Ericson
d3407f1a3b cc-wrapper: Add support for -mthumb / -marm 2021-09-17 17:12:54 +00:00
Shea Levy
9ecfbe0c5b
mingw: Disalbe FORTIFY_SOURCE by default.
In newer versions of mingw, programs compiled with FORTIFY_SOURCE need
to link to libssp or they will have link-time errors.

gmp has been broken since @pstn updated mingw-64 in c60a0b0447
2021-08-11 05:07:42 -04:00
sternenseemann
c3c4ef859a gprbuild, xmlada: init at 21.0.0
GPRbuild is a multi language build system developed by AdaCore which
is mostly used for build Ada-related projects using GNAT.

Since GPRbuild is used to build itself and its dependency library
XML/Ada we first build a bootstrap version of it using the provided
bash build script bootstrap.sh as the gprbuild-boot derivation.
gprbuild-boot is then used to build xmlada and the proper gprbuild
derivation.

GPRbuild has its own search path mechanism via GPR_PROJECT_PATH which
we address via a setupHook. It currently works quite similar to the
pkg-config one: It accumulates all inputs into GPR_PROJECT_PATH,
GPR_PROJECT_PATH_FOR_BUILD etc. However this is quite limited at the
moment as we don't have a gprbuild wrapper yet which understands the
_FOR_BUILD suffix. However, we'll need to address this in the future
as it is currently basically impossible to test since the distinction
only affects cross-compilation, but it is not possible to build a GNAT
cross-compiler in nixpkgs at the moment (I'm working on changing that,
however).

Another issue we had to solve was GPRbuild not finding the right GNAT
via its gprconfig tool: GPRbuild has a knowledge base with compiler
definitions which run some checks and collect info about binaries
which are in PATH. In the end the first compiler in PATH that supports
the desired language is selected.

We want GPRbuild to discover our wrapped GNAT since the unwrapped one
is incapable of producing working binaries since it won't find the
crt*.o objects distributed with libc. GPRbuild however needs to find
the Ada runtime distributed with GNAT which is not part of the wrapper
derivation, so it will skip the wrapper and select the unwrapped GNAT.
Symlinking the unwrapped's lib directory into the wrapper fixes this
problem, but breaks linking in some cases (e. g. when linking against
OMP from gcc, the runtime variant will shadow the problem dynamic lib
from buildInputs). Additionally it uses gnatls as an indicator it has
found GNAT which is not part of the wrapper.

The solution we opted to adopt here is to install a custom compiler
description into gprbuild's knowledge base which properly detects the
nixpkgs GNAT wrapper: It uses gnatmake to detect GNAT instead of
gnatls and discovers the runtime via a symlink we add to
`$out/nix-support`. This additional definition is enough to properly
detect GNAT, since the plain wrapped gcc detection works out of the
box. It may, however, be necessary to add special definitions for
other languages in the future where gprbuild also needs to discover
the runtime.

One future improvement would be to install libgpr into a separate
output or split it into a separate derivation (which would require to
link gprbuild statically always since otherwise we end up with a
cyclical dependency).
2021-08-03 14:58:49 +02:00
Jörg Thalheim
166948d479 cc-wrapper: don't set rpath on static-pie executables 2021-05-23 17:38:17 +00:00
John Ericson
18c38f8aee treewide: All the linker to be chosen independently
This will begin the process of breaking up the `useLLVM` monolith. That
is good in general, but I hope will be good for NetBSD and Darwin in
particular.

Co-authored-by: sterni <sternenseemann@systemli.org>
2021-05-14 21:29:51 +00:00
John Ericson
912c8262b4
Merge pull request #117591 from s1341/android_non_prebuilt
treewide: Support aarch64-android using minimal prebuilt components
2021-05-11 12:49:53 -04:00
s1341
1e1d29c2af treewide: Support aarch64-android using minimal prebuilt components
This PR adds a new aarch64 android toolchain, which leverages the
existing crossSystem infrastructure and LLVM builders to generate a
working toolchain with minimal prebuilt components.

The only thing that is prebuilt is the bionic libc. This is because it
is practically impossible to compile bionic outside of an AOSP tree. I
tried and failed, braver souls may prevail. For now I just grab the
relevant binaries from https://android.googlesource.com/.

I also grab the msm kernel sources from there to generate headers. I've
included a minor patch to the existing kernel-headers derivation in
order to expose an internal function.

Everything else, from binutils up, is using stock code. Many thanks to
@Ericson2314 for his help on this, and for building such a powerful
system in the first place!

One motivation for this is to be able to build a toolchain which will
work on an aarch64 linux machine. To my knowledge, there is no existing
toolchain for an aarch64-linux builder and an aarch64-android target.
2021-05-11 15:39:08 +00:00
Vladimír Čunát
8eabe2ecc5
Merge #115235: gcc: native aarch64-darwin support 2021-05-11 12:12:04 +02:00
Ivan Babrou
4aa95e3312 gcc: native aarch64-darwin support 2021-05-10 19:07:30 -07:00
Dmitry Kalinkin
11b744b59c
cc-wrapper.sh: make -nostdlib disable the standard C++ library, but not its includes
Should be the correct fix for #111970
2021-05-02 14:07:00 -04:00
Dmitry Kalinkin
d9bad0eae6
cc-wrapper.sh: rename variables cpp -> cxx
CPP is the C PreProcessor
CXX is C++
2021-05-02 14:03:51 -04:00
Dmitry Kalinkin
96bbe339d4
Revert "cc-wrapper: -nostdlib does not imply -nostdinc++"
This made C++ standard headers passed to be passed when C compiler is
executed, which is not a correct fix.

This reverts commit 54c7a0f422.
2021-05-02 14:00:37 -04:00
Andrew Childs
7869d16545 llvmPackages: Multuple outputs for everythting
Also begin to start work on cross compilation, though that will have to
be finished later.

The patches are based on the first version of
https://reviews.llvm.org/D99484. It's very annoying to do the
back-porting but the review has uncovered nothing super major so I'm
fine sticking with what I've got.

Beyond making the outputs work, I also strove to re-sync the packages,
as they have been drifting pointlessly apart for some time.

----

Other misc notes, highly incomplete

- lvm-config-native and llvm-config are put in `dev` because they are
  tools just for build time.

- Clang no longer has an lld dep. That was introduced in
  db29857eb3, but if clang needs help
  finding lld when it is used we should just pass it flags / put in the
  resource dir. Providing it at build time increases critical path
  length for no good reason.

----

A note on `nativeCC`:

`stdenv` takes tools from the previous stage, so:

1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.stdenv.cc`: `(?0, ?1, x)`

while:

1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.targetPackages`: `(x, x, ?2)`
3. `pkgsBuildBuild.targetPackages.stdenv.cc`: `(?1, x, x)`
2021-04-30 05:41:00 +00:00
Luke Granger-Brown
08b22e605b Merge remote-tracking branch 'upstream/staging-next' into down-integrate-staging 2021-04-12 18:49:01 +00:00
Andrew Childs
6c4ce7960e bintools-wrapper, cc-wrapper: parameterize darwin min version variable
These variables are the ones that the standard toolchain uses, so we
should use those and not always use MACOSX_DEPLOYMENT_TARGET.

See 236a426c12/cctools/ld64/src/ld/PlatformSupport.cpp (L54-L55)
2021-04-11 09:47:10 +09:00
Andrew Childs
2a9b3b4943 cc-wrapper, bintools-wrapper: support MACOSX_DEPLOYMENT_TARGET with roles
In a typical build environment the toolchain will use the value of the
MACOSX_DEPLOYMENT_TARGET environment variable to determine the version
of macOS to support. When cross compiling there are two distinct
toolchains, but they will look at this single environment variable. To
avoid contamination, we always set the equivalent command line flag
which effectively disables the toolchain's internal handling.

Prior to this change, the MACOSX_DEPLOYMENT_TARGET variable was
ignored, and the toolchains always used the Nix platform
definition (`darwinMinVersion`) unless overridden with command line
arguments.

This change restores support for MACOSX_DEPLOYMENT_TARGET, and adds
nix-specific MACOSX_DEPLOYMENT_TARGET_FOR_BUILD and
MACOSX_DEPLOYMENT_TARGET_FOR_TARGET for cross compilation.
2021-04-11 09:47:10 +09:00
Andrew Childs
8b59d52ca3 cc-wrapper: use legacy -mmacosx-version-min for gcc
See https://github.com/NixOS/nixpkgs/pull/105026#discussion_r587169144
2021-04-11 09:47:10 +09:00
Andrew Childs
362cb82b75 cc-wrapper: specify default -mmacos-version-min
This avoids contamination via MACSOX_DEPLOYMENT_TARGET when cross
compiling.
2021-04-11 09:47:10 +09:00
arcnmx
2f1131cff7 cc-wrapper: match useGccForLibs conditional order
This breaks an evaluation cycle between `cc` and `gccForLibs` for cross
builds, fixing an infinite recursion error.
2021-04-10 10:39:07 -07:00
Thomas Tuegel
54c7a0f422 cc-wrapper: -nostdlib does not imply -nostdinc++
The check for including the C++ standard library headers was nested inside the
check for linking with the C++ standard library. As a result, the `-nostdlib`
flag incorrectly implied `-nostdinc++`, which made it virtually impossible to
partially link C++ objects.
2021-03-20 09:26:04 +01:00
Andrew Childs
86e962a41a cc-wrapper: remove quoting of response file
Fixes build failures with clang:

    clang-7: error: unknown argument: '-fPIC                -target'
    clang-7: error: no such file or directory: '@<(printf %qn        -O2'
    clang-7: error: no such file or directory: 'x86_64-apple-darwin'

Introduced by 60c5cf9cea in #112449
2021-03-09 14:01:34 +09:00
John Ericson
6979a72840
Merge pull request #112449 from angerman/angerman/response-files
Add response file support when compiling with clang
2021-03-06 11:24:32 -05:00
Jan Tojnar
6d1958ad2d
Merge branch 'staging-next' into staging 2021-03-04 22:16:45 +01:00
s1341
aee60bef7a android_prebuilt: Fix eval 2021-03-04 18:17:39 +00:00
Andrew Childs
fc0456bed1 cc-wrapper: set -arch on darwin 2021-03-02 17:21:08 +09:00
Moritz Angermann
60c5cf9cea
Update pkgs/build-support/cc-wrapper/cc-wrapper.sh
Co-authored-by: Matthew Bauer <mjbauer95@gmail.com>
2021-02-26 10:07:27 +08:00
Walter Franzini
eabb56ac6c identify musl32 using x86_32 instead of i686 2021-02-12 21:11:16 +01:00
Walter Franzini
87e35291a5 disable stackprotector on target platform musl32 2021-02-12 11:06:29 +01:00
Moritz Angermann
11b4d6c633
responsie file logic 2021-02-09 09:46:47 +08:00
Ben Siraphob
aa8868c7cc pkgs/build-support: stdenv.lib -> lib 2021-01-24 19:07:54 -08:00
John Ericson
0710308402 clang, cc-wrapper: Move --gcc-toolchain logic into CC wrapper
Take 2, after #94582 had to be reverted.

This reverts commit ac03cfa3c5.
2021-01-24 15:49:32 -05:00
John Ericson
9c213398b3 lib: Clean up how linux and gcc config is specified
Second attempt of 8929989614589ee3acd070a6409b2b9700c92d65; see that
commit for details.

This reverts commit 0bc275e634.
2021-01-23 10:01:28 -05:00
Jonathan Ringer
0bc275e634
Revert "lib: Clean up how linux and gcc config is specified"
This is a stdenv-rebuild, and should not be merged
into master

This reverts commit 8929989614.
2021-01-22 14:07:06 -08:00
John Ericson
8929989614 lib: Clean up how linux and gcc config is specified
The `platform` field is pointless nesting: it's just stuff that happens
to be defined together, and that should be an implementation detail.

This instead makes `linux-kernel` and `gcc` top level fields in platform
configs. They join `rustc` there [all are optional], which was put there
and not in `platform` in anticipation of a change like this.

`linux-kernel.arch` in particular also becomes `linuxArch`, to match the
other `*Arch`es.

The next step after is this to combine the *specific* machines from
`lib.systems.platforms` with `lib.systems.examples`, keeping just the
"multiplatform" ones for defaulting.
2021-01-21 22:44:09 -05:00
Steven Pease
b766673c6f Move disabling of gccForLibs for iOS to build-support cc-wrapper 2021-01-20 10:14:46 -08:00
Jörg Thalheim
61bbbcd1af
bintools-wrapper: skip dynamic linker for static binaries 2020-12-27 16:42:11 +01:00
John Ericson
fb875dcf6f
Merge pull request #107507 from LibreCybernetics/add-zen-info
lib.systems: update processor architecture info
2020-12-24 10:23:10 -05:00
Fabián Heredia Montiel
2a9ac172c1 lib.systems: update processor architecture info 2020-12-23 18:57:59 -06:00
Florian Klink
07c4056179 gnats: format hardened flag isn't supported
When invoking a simple Ada program with `gcc` from `gnats10`, the
following warnings are shown:

```
$ gcc -c conftest.adb
gnat1: warning: command-line option ‘-Wformat=1’ is valid for C/C++/ObjC/ObjC++ but not for Ada
gnat1: warning: command-line option ‘-Wformat-security’ is valid for C/C++/ObjC/ObjC++ but not for Ada
gnat1: warning: ‘-Werror=’ argument ‘-Werror=format-security’ is not valid for Ada
$ echo $?
0
```

This is only spammy when compiling Ada programs inside a Nix derivation,
but certain configure scripts (such as the ./configure script from the
gcc that's built by coreboot's `make crossgcc` command) fail entirely
when getting that warning output.

https://nixos.wiki/wiki/Coreboot currently suggests manually running

> NIX_HARDENING_ENABLE="${NIX_HARDENING_ENABLE/ format/}" make crossgcc

… but actually teaching the nixpkgs-provided cc wrapper that `format`
isn't supported as a hardening flag seems to be the more canonical way
to do this in nixpgks.

After this, Ada programs still compile:

```
$ gcc -c conftest.adb
$ echo $?
0
```

And the compiler output is empty.
2020-12-23 01:51:14 +01:00
Matthew Bauer
989b403c7f
Merge pull request #96318 from matthewbauer/provide-patchelf-in-native-stdenv
stdenv/native: provide patchelf on linux
2020-10-30 13:32:13 -05:00
Matthew Bauer
4830967736 Fix cc-wrapper in native stdenv 2020-08-26 14:36:26 -05:00
Frederik Rietdijk
d59c57f8a6
Merge pull request #92412 from matthewbauer/blas-cross
Blas/Lapack cross fixes
2020-08-15 08:55:57 +02:00
John Ericson
b5f7ed6846
Merge pull request #91293 from Ericson2314/cxx-wrapper-debt-part-2
treewide: Get rid of `cc.gcc`
2020-08-02 20:42:20 -04:00
John Ericson
92f96f47b0 treewide: Get rid of cc.gcc
Instead, we have a new `gccForLibs`, which has the appropriate
definition for e.g. avoiding `x86_32` linking problems.
2020-08-02 17:12:05 +00:00
Jörg Thalheim
96092dc936
stdenv: make -nostdinc work as intended
Right now we add glibc to search path also -nostdinc was provided,
which breaks projects providing their own gcc.
2020-07-23 08:39:46 +01:00