when I got gcc source from gcc-mirror(https://github.com/gcc-mirror/gcc),and build it with nix,it complained missing gengtype-lex.c。I found current standard environment don’t include flex package,
would it be better if nixpkgs include flex,when building gcc package?
gcc releases don’t require flex and thus derivations don’t pull it in as a dependency. If you want to build a gcc snapshot or gcc from git tree you will need to add flex as an explicit dependency into your derivation.
It’s too little detail to say definitely. Usually nix shows a hint to run nix log /path/to/drv to get more detailed log. But in this case my guess is that SIGSEGV is a sign of out-of-memory condition. dmesg should show if OOM happened and what was resource usage of processes at OOM time.
If you don’t have enough RAM you might want to try lower parallelism with --cores.
the overlay file for gcc9 is like above. Once I build gcc9 with this overlay,it‘s been stuck in the building of bootstrap-stage0-stdenv-linux.drv,it show the error:
And machine memory is enough,110G avaliable。
Last but not least,this overlay file works for gcc7,8,10,and 11,except for gcc9.
Have you ever sucessfully rebuilt gcc9 package ?
I build gcc9 (as 9.4.0) from staging locally a few times a week without any problems. I don’t apply custom patches to it though. I suggest looking at the build log to get better idea where SIGSEGV happens…
Which nix version you are using? I personally patch gcc right in nixpkgs/master checkout and don’t use an overlay. If you don’t see a log perhaps the overlay definition is wrong. Does it take a while to fail for you?
try both 2.3.16 and 2.4pre-rc1,It takes a long time to be failure.And the overlay don’t have semantic error,and the buildInputs can remove,because the build is stop before gcc compilation(flex raises problem you stated in github).
After fixing 2 typos (overrideAttrs with 2 t but only 1 r and adding import in gcc.nix) it failed during patchPhase, as all patches are skipped, if I understand the log correctly:
If I then also add patches = []; to the override it starts building. And as far as I can tell it skipped the bootstrapping…
Lets see how long it takes, then I’ll report back.
./result/bin/gcc --version
gcc (GCC) 9.4.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I built from nixos/nixpkgs commit 6daa4a5c045d40e6eae60a3b6e427e8700f1c07f (nixpkgs-unstable)
sorry, I manually wrote the code on this post with some typos,but the code on my server don’t have typo。Then I will try to add the patches=[],and build again,thanks !
I noticed that building gcc8 don’t have this step building '/nix/store/z3gcsyzg8fjb29qxb1zdn7psqzngx082-bootstrap-stage0-stdenv-linux.drv,but gcc9 happenned. And I am still failed in this, not reaching patchPhase.
When you built gcc9, was the bootstrap-stage0-stdenv-linux.drv ever built ?I don’t know why it built bootstrap-stage0-binutils-wrapper-.drv,one of its inputDrvs is just bootstrap-stage0-stdenv-linux.drv.I think, when I built gcc9,it trigerred the bootstapping of binutils and glibc and others.
inherit (let
num =
if (with stdenv.targetPlatform; isVc4 || libc == "relibc") then 6
else if (stdenv.targetPlatform.isAarch64 && stdenv.isDarwin) then 11
else if stdenv.targetPlatform.isAarch64 then 9
else 10;
numS = toString num;
in {
gcc = pkgs.${"gcc${numS}"};
gccFun = callPackage (../development/compilers/gcc + "/${numS}");
}) gcc gccFun;
gcc-unwrapped = gcc.cc;
On x86_64gcc9 is not a bootstrap compiler and just a mere package. You don’t need to rebuild much to get it. arm64 is the only target where it’s the case.