| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
|
|
| |
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>
|
|\
| |
| | |
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.
|
|\ \
| |/
|/| |
|
| | |
|
| |
| |
| |
| |
| |
| | |
includes
Should be the correct fix for #111970
|
| |
| |
| |
| |
| | |
CPP is the C PreProcessor
CXX is C++
|
| |
| |
| |
| |
| |
| |
| | |
This made C++ standard headers passed to be passed when C compiler is
executed, which is not a correct fix.
This reverts commit 54c7a0f42287f63c2db8086a8ad46ac981364378.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
db29857eb391ed002046090851a44c452b80bdbd, 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)`
|
|\ |
|
| |
| |
| |
| |
| | |
This breaks an evaluation cycle between `cc` and `gccForLibs` for cross
builds, fixing an infinite recursion error.
|
| |
| |
| |
| |
| |
| |
| | |
These variables are the ones that the standard toolchain uses, so we
should use those and not always use MACOSX_DEPLOYMENT_TARGET.
See https://github.com/tpoechtrager/cctools-port/blob/236a426c1205a3bfcf0dbb2e2faf2296f0a100e5/cctools/ld64/src/ld/PlatformSupport.cpp#L54-L55
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| | |
See https://github.com/NixOS/nixpkgs/pull/105026#discussion_r587169144
|
|/
|
|
|
| |
This avoids contamination via MACSOX_DEPLOYMENT_TARGET when cross
compiling.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
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 60c5cf9cea56ffd607b48fe07ff1174ea6a13afc in #112449
|
|\
| |
| | |
Add response file support when compiling with clang
|
| |
| |
| | |
Co-authored-by: Matthew Bauer <mjbauer95@gmail.com>
|
| | |
|
|\ \ |
|
| | | |
|
|/ / |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
Take 2, after #94582 had to be reverted.
This reverts commit ac03cfa3c57027e82073ea7db71248d4ab78af66.
|
| |
| |
| |
| |
| |
| |
| | |
Second attempt of 8929989614589ee3acd070a6409b2b9700c92d65; see that
commit for details.
This reverts commit 0bc275e63423456d6deb650e146120c39c1e0723.
|
| |
| |
| |
| |
| |
| |
| | |
This is a stdenv-rebuild, and should not be merged
into master
This reverts commit 8929989614589ee3acd070a6409b2b9700c92d65.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| | |
|
|\ \
| | |
| | | |
lib.systems: update processor architecture info
|
| | | |
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\ \
| | |
| | | |
stdenv/native: provide patchelf on linux
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | | |
A few thousand rebuilds per platform have arrived in the meantime.
|
| |\ \ \
| | | | |
| | | | | |
cc-wrapper: Fix for prebuilt android
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We don't want to use Nix-built GCC's libs with prebuilt clang in this
case.
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | | |
Follow up to the revert in e560459c5b06ce1351ae5eb8988f8ce87602058a.
This reverts commit 1936b11f63d2f58ef0c7216e53e56deb804a715e.
|
|/ / / |
|
|\ \ \
| |/ /
|/| | |
platform.gcc.arch: support for AMD CPUs
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | | |
Blas/Lapack cross fixes
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We need to set FC so that CMake and other tools can find the fortran
compiler. Also we need to limit the hardening flags since fortify and
format don’t work with fortran.
Fixes #88449
|
|\ \ \ \
| |_|/ /
|/| | | |
treewide: Get rid of `cc.gcc`
|