summary refs log tree commit diff
path: root/pkgs/build-support/cc-wrapper
Commit message (Collapse)AuthorAge
* Check link type based on expanded parametersMoritz Angermann2022-01-01
| | | | | | | | 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.
* Merge pull request #135619 from r-burns/fpie-musl-fixesr-burns2021-09-23
|\ | | | | [staging] {cc,binutils}-wrapper: fixes for PIE hardening
| * {cc,binutils}-wrapper: match leading/trailing argumentsRyan Burns2021-09-20
| | | | | | | | | | | | | | | | | | | | | | 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
| * cc-wrapper: ensure PIE flags precede PIC flagsRyan Burns2021-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* | cc-wrapper: Add support for -mthumb / -marmJohn Ericson2021-09-17
|/
* mingw: Disalbe FORTIFY_SOURCE by default.Shea Levy2021-08-11
| | | | | | | 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 c60a0b044747037b87e7ec24b60d221e261b8a6b
* gprbuild, xmlada: init at 21.0.0sternenseemann2021-08-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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).
* cc-wrapper: don't set rpath on static-pie executablesJörg Thalheim2021-05-23
|
* treewide: All the linker to be chosen independentlyJohn Ericson2021-05-14
| | | | | | | | 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>
* Merge pull request #117591 from s1341/android_non_prebuiltJohn Ericson2021-05-11
|\ | | | | treewide: Support aarch64-android using minimal prebuilt components
| * treewide: Support aarch64-android using minimal prebuilt componentss13412021-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Merge #115235: gcc: native aarch64-darwin supportVladimír Čunát2021-05-11
|\ \ | |/ |/|
| * gcc: native aarch64-darwin supportIvan Babrou2021-05-10
| |
* | cc-wrapper.sh: make -nostdlib disable the standard C++ library, but not its ↵Dmitry Kalinkin2021-05-02
| | | | | | | | | | | | includes Should be the correct fix for #111970
* | cc-wrapper.sh: rename variables cpp -> cxxDmitry Kalinkin2021-05-02
| | | | | | | | | | CPP is the C PreProcessor CXX is C++
* | Revert "cc-wrapper: -nostdlib does not imply -nostdinc++"Dmitry Kalinkin2021-05-02
| | | | | | | | | | | | | | This made C++ standard headers passed to be passed when C compiler is executed, which is not a correct fix. This reverts commit 54c7a0f42287f63c2db8086a8ad46ac981364378.
* | llvmPackages: Multuple outputs for everythtingAndrew Childs2021-04-30
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)`
* Merge remote-tracking branch 'upstream/staging-next' into down-integrate-stagingLuke Granger-Brown2021-04-12
|\
| * cc-wrapper: match useGccForLibs conditional orderarcnmx2021-04-10
| | | | | | | | | | This breaks an evaluation cycle between `cc` and `gccForLibs` for cross builds, fixing an infinite recursion error.
* | bintools-wrapper, cc-wrapper: parameterize darwin min version variableAndrew Childs2021-04-11
| | | | | | | | | | | | | | 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
* | cc-wrapper, bintools-wrapper: support MACOSX_DEPLOYMENT_TARGET with rolesAndrew Childs2021-04-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | cc-wrapper: use legacy -mmacosx-version-min for gccAndrew Childs2021-04-11
| | | | | | | | See https://github.com/NixOS/nixpkgs/pull/105026#discussion_r587169144
* | cc-wrapper: specify default -mmacos-version-minAndrew Childs2021-04-11
|/ | | | | This avoids contamination via MACSOX_DEPLOYMENT_TARGET when cross compiling.
* cc-wrapper: -nostdlib does not imply -nostdinc++Thomas Tuegel2021-03-20
| | | | | | | 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.
* cc-wrapper: remove quoting of response fileAndrew Childs2021-03-09
| | | | | | | | | | 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
* Merge pull request #112449 from angerman/angerman/response-filesJohn Ericson2021-03-06
|\ | | | | Add response file support when compiling with clang
| * Update pkgs/build-support/cc-wrapper/cc-wrapper.shMoritz Angermann2021-02-26
| | | | | | Co-authored-by: Matthew Bauer <mjbauer95@gmail.com>
| * responsie file logicMoritz Angermann2021-02-09
| |
* | Merge branch 'staging-next' into stagingJan Tojnar2021-03-04
|\ \
| * | android_prebuilt: Fix evals13412021-03-04
| | |
* | | cc-wrapper: set -arch on darwinAndrew Childs2021-03-02
|/ /
* | identify musl32 using x86_32 instead of i686Walter Franzini2021-02-12
| |
* | disable stackprotector on target platform musl32Walter Franzini2021-02-12
| |
* | pkgs/build-support: stdenv.lib -> libBen Siraphob2021-01-24
| |
* | clang, cc-wrapper: Move `--gcc-toolchain` logic into CC wrapperJohn Ericson2021-01-24
| | | | | | | | | | | | Take 2, after #94582 had to be reverted. This reverts commit ac03cfa3c57027e82073ea7db71248d4ab78af66.
* | lib: Clean up how linux and gcc config is specifiedJohn Ericson2021-01-23
| | | | | | | | | | | | | | Second attempt of 8929989614589ee3acd070a6409b2b9700c92d65; see that commit for details. This reverts commit 0bc275e63423456d6deb650e146120c39c1e0723.
* | Revert "lib: Clean up how linux and gcc config is specified"Jonathan Ringer2021-01-22
| | | | | | | | | | | | | | This is a stdenv-rebuild, and should not be merged into master This reverts commit 8929989614589ee3acd070a6409b2b9700c92d65.
* | lib: Clean up how linux and gcc config is specifiedJohn Ericson2021-01-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Move disabling of gccForLibs for iOS to build-support cc-wrapperSteven Pease2021-01-20
| |
* | bintools-wrapper: skip dynamic linker for static binariesJörg Thalheim2020-12-27
| |
* | Merge pull request #107507 from LibreCybernetics/add-zen-infoJohn Ericson2020-12-24
|\ \ | | | | | | lib.systems: update processor architecture info
| * | lib.systems: update processor architecture infoFabián Heredia Montiel2020-12-23
| | |
* | | gnats: format hardened flag isn't supportedFlorian Klink2020-12-23
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Merge pull request #96318 from matthewbauer/provide-patchelf-in-native-stdenvMatthew Bauer2020-10-30
|\ \ | | | | | | stdenv/native: provide patchelf on linux
| * | Fix cc-wrapper in native stdenvMatthew Bauer2020-08-26
| | |
* | | gnat: fix buildLars Jellema2020-09-19
| | |
* | | Merge branch 'master' into staging-nextVladimír Čunát2020-09-11
|\ \ \ | | | | | | | | | | | | A few thousand rebuilds per platform have arrived in the meantime.
| * \ \ Merge pull request #97387 from Ericson2314/fix-android-prebuiltJohn Ericson2020-09-08
| |\ \ \ | | | | | | | | | | cc-wrapper: Fix for prebuilt android
| | * | | cc-wrapper: Fix for prebuilt androidJohn Ericson2020-09-07
| | | | | | | | | | | | | | | | | | | | | | | | | We don't want to use Nix-built GCC's libs with prebuilt clang in this case.
* | | | | Revert "utils.bash: also "fix" cc-wrapper and pkg-config-wrapper"Frederik Rietdijk2020-09-07
|/ / / / | | | | | | | | | | | | | | | | | | | | Follow up to the revert in e560459c5b06ce1351ae5eb8988f8ce87602058a. This reverts commit 1936b11f63d2f58ef0c7216e53e56deb804a715e.
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-06-29 11:50:43 +0000