about summary refs log tree commit diff
path: root/pkgs/development/compilers/gcc
AgeCommit message (Collapse)AuthorFilesLines
2023-11-08Merge staging-next into staginggithub-actions[bot]8-4/+293
2023-11-08Merge master into staging-nextgithub-actions[bot]8-4/+293
2023-11-08Update pkgs/development/compilers/gcc/patches/default.nixAdam Joseph1-1/+1
2023-11-08gcc{48,49,6,7,8,9,10}: improve cctools-llvm compatibilityRandy Eckenrode1-0/+6
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.
2023-11-08gcc{48,49,6,7,8,9,10}: fix missing symbol errors on x86_64-darwinRandy Eckenrode2-0/+37
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.
2023-11-08gcc{8,9}: don’t pass --gstabs to clang assemblerRandy Eckenrode3-0/+203
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.
2023-11-08gcc{48,49,6}: don’t use -pipe with clang assemblerRandy Eckenrode2-0/+22
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.
2023-11-08gcc11: fix build on aarch64-darwinRandy Eckenrode2-0/+24
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.
2023-11-08gcc48: disable on x86_64-darwinRandy Eckenrode2-4/+1
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.
2023-11-07Merge staging-next into staginggithub-actions[bot]3-24/+95
2023-11-07Merge master into staging-nextgithub-actions[bot]3-24/+95
2023-11-07gcc: move version iteration out of all-packages.nixAdam Joseph1-0/+53
This resolves a TODO previously in all-packages.nix.
2023-11-07gcc: move version information to gcc/versions.nixAdam Joseph2-24/+42
2023-11-04Merge staging-next into staginggithub-actions[bot]1-2/+2
2023-11-04Merge master into staging-nextgithub-actions[bot]1-2/+2
2023-11-04gcc.libgcc: compare host and target platforms, rathern than their triplesAdam Joseph1-2/+2
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.
2023-10-27Merge pull request #240596 from amjoseph-nixpkgs/pr/gcc/stage-renameArtturi1-2/+2
2023-10-26gcc: change "-stage-static" to "-nolibc" and "-stage-final" to ""Adam Joseph1-2/+2
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>
2023-10-26Merge branch 'staging' into staging-nextVladimír Čunát3-2/+171
2023-10-25gcc: create dummy crtstuff on S390 as wellAdam Joseph1-3/+4
This commit replicates the fix in https://github.com/NixOS/nixpkgs/pull/258032 for S390 as well. Co-authored-by: Artturi <Artturin@artturin.com>
2023-10-22Merge staging-next into staginggithub-actions[bot]1-4/+19
2023-10-22gcc: create dummy crtstuff on loongarch64Weijia Wang1-4/+19
2023-10-11Merge staging-next into staginggithub-actions[bot]1-3/+2
2023-10-11Merge master into staging-nextgithub-actions[bot]1-3/+2
2023-10-10gcc: always inhibit libc in cross with same configsAlyssa Ross1-3/+2
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: 926c920c1270 ("gcc: tighten condition for inhibit_libc=true")
2023-10-08Merge staging-next into staginggithub-actions[bot]1-1/+1
2023-10-08Merge remote-tracking branch 'origin/master' into staging-nextFabián Heredia Montiel1-1/+1
2023-10-08Merge pull request #255192 from trofi/cc-wrapper-no-__FILE_-refsArtturi3-2/+171
2023-10-07gcc: add fallback to conditionArtturin1-1/+1
``` > pkgsMusl.nix error: attribute 'useLLVM' missing $ nix eval -f . pkgsMusl.pkgsStatic.stdenv.targetPlatform.useLLVM error: attribute 'useLLVM' in selection path 'pkgsMusl.pkgsStatic.stdenv.targetPlatform.useLLVM' not found ```
2023-10-05Merge remote-tracking branch 'origin/master' into staging-nextAlyssa Ross1-1/+4
The hash for pytensor is not correct, but that's also the case in master, so a merge commit isn't the place to fix it. Conflicts: pkgs/development/python-modules/faadelays/default.nix pkgs/development/python-modules/pytensor/default.nix pkgs/tools/admin/rset/default.nix
2023-10-05Merge pull request #241206 from amjoseph-nixpkgs/tighten-inhibit_libc-conditionArtturi1-1/+4
2023-10-04gcc12, gcc13: always mangle __FILE__ into invalid store pathSergei Trofimovich3-2/+171
Without the change `__FILE__` used in static inline functions in headers embed paths to header files into executable images. For local headers it's not a problem, but for headers in `/nix/store` this causes `-dev` inputs to be retained in runtime closure. Typical examples are `nix` -> `nlonhmann_json` and `pipewire` -> `lttng-ust.dev`. Ideally we would like to use `-fmacro-prefix-map=` feature of `gcc` as: -fmacro-prefix-map=/nix/store/$hash1-nlohmann-json-ver=/nix/store/eeee.eee-nlohmann-json-ver -fmacro-prefix-map=/nix/... In practice it quickly exhausts argument lengtth limit due to `gcc` deficiency: https://gcc.gnu.org/PR111527 Until it;s fixed let's hardcode header mangling if $NIX_STORE variable is present in the environment. Tested as: $ printf "# 0 \"/nix/store/01234567890123456789012345678901-pppppp-vvvvvvv\" \nconst char * f(void) { return __FILE__; }" | NIX_STORE=/nix/store ./gcc/xgcc -Bgcc -x c - -S -o - ... .string "/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-pppppp-vvvvvvv" ... Mangled successfully.
2023-09-22Merge staging-next into staginggithub-actions[bot]2-0/+13
2023-09-21gcc: set GFORTRAN_FOR_TARGET on cross-built native compilersAdam Joseph2-0/+13
For a cross-built native compiler, i.e. build!=(host==target), the bundled libgfortran needs a gfortran which can run on the buildPlatform and emit code for the targetPlatform. The compiler which is built alongside gfortran in this configuration doesn't meet that need: it runs on the hostPlatform. This commit passes the necessary compiler via `GFORTRAN_FOR_TARGET`, using `pkgsBuildTarget.gfortran`.
2023-09-19Merge pull request #250498 from amjoseph-nixpkgs/gcc/deduplicate/simplify2Artturi1-9/+5
2023-09-09Merge master into staging-nextgithub-actions[bot]3-3/+3
2023-09-08Merge pull request #253939 from angerman/angerman/ucrt64John Ericson3-3/+3
Add ucrt64 mingw toolchain.
2023-09-09Merge master into staging-nextgithub-actions[bot]2-5/+22
2023-09-08gcc: for cross compilers, don't build libgcc twiceAdam Joseph2-5/+22
Cross-compiled binaries currently end up with two different libgcc outpaths in their closure. This is harmless, but confusing. The two libgccs are: - One of them is the "first" targetPlatform libgcc, which is built by the "first" cross-compiler. This "first libgcc" and "first compiler" are used to build the targetPlatform glibc. - Once glibc is built, we *rebuild* the cross-compiler, since gcc can't enable most of its features unless you give it an already-compiled targetPlatform glibc. When this "second" compiler is built, it also builds an extra copy of libgcc. This commit discards the second, extra libgcc, and instead puts a reference to the first (correct) libgcc into the "second compiler" `.passthru.libgcc`, so that anybody expecting `stdenv.cc.cc.libgcc` to exist will still find it there. Closes #249680
2023-09-08treewide: replace libc == "msvcrt" with isMinGWMoritz Angermann3-3/+3
msvcrt is only one of the libcs in MinGW. We therefore replace explictly testing for msvcrt with the isMinGW predicate. This lays the foundation for ucrt64 support.
2023-09-06Merge pull request #250496 from amjoseph-nixpkgs/simplifyArtturi1-99/+163
2023-09-02gcc.patches: For gcc49 apply libsanitizer-no-cyclades-9 patch laterArtturin1-1/+4
otherwise there is a conflict
2023-08-29gcc: move dll.a in lib64 to lib output tooArtturin1-0/+1
same as c304c1e7d0f5bc673c8e7626bfe09270caf5f733
2023-08-27gcc: move dll to outputmarius david1-0/+2
2023-08-23gcc: unescapify backslashAdam Joseph1-1/+1
2023-08-23gcc: remove backticks-used-as-quotes (error prone)Adam Joseph1-2/+2
2023-08-23gcc: simplify expression by applying workarounds more broadlyAdam Joseph1-8/+4
This commit simplifies our gcc expression by applying various workarounds unconditionally, rather than only to exactly the versions which applied them prior to the deduplication cleanup. Unlike its predecessors https://github.com/NixOS/nixpkgs/pull/249707 and https://github.com/NixOS/nixpkgs/pull/250489 this commit *does* affect eval.
2023-08-23gcc: limit gcc12 isMips `--disable-libsanitizer` to abi=="gnu"Adam Joseph1-1/+1
2023-08-23gcc12: disable libsanitizer for mips64Sergei Trofimovich1-0/+5
Without the change build on mips64-unknown-linux-gnu fails as: $ nix-build -A buildPackages.gcc12 --argstr crossSystem mips64-linux In file included from ...-glibc-mips64-unknown-linux-gnu-2.37-8-dev/include/bits/stat.h:25, from ...-glibc-mips64-unknown-linux-gnu-2.37-8-dev/include/fcntl.h:78, from ../../../../gcc-12.3.0/libsanitizer/sanitizer_common/sanitizer_linux.cpp:55: ...-glibc-mips64-unknown-linux-gnu-2.37-8-dev/include/bits/struct_stat.h:190:8: error: redefinition of 'struct stat64' 190 | struct stat64 | ^~~~~~
2023-08-21gcc: patches: reorganize and simplifyAdam Joseph1-99/+160
This PR sorts the huge pile of patches and deduplicates it. Unlike its predecessors https://github.com/NixOS/nixpkgs/pull/249707 and https://github.com/NixOS/nixpkgs/pull/250489 this commit *does* affect eval. Patches below are organized into three general categories: 1. Patches relevant to gcc>=12 on every platform 2. Patches relevant to gcc>=12 on specific platforms 3. Patches relevant only to gcc<12, sorted by the newest version to which they might be relevant
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-09-18 10:52:11 +0000