Hi,
Thanks for the response! Though I must admit it's quite... dense for me
still, being a Nix noob... thus I'll let myself follow up with some more
questions, as I'm desperately trying to wrap my head around the stuff...
So, first of all, regarding bootstrapping: I'm afraid I'm not yet really
sure what it means in Nix/NixOS. I get it that it's apparently not related
to what's usually understood as "OS bootstrapping" (i.e. bootstrap loader,
GRUB, etc.) - or is it? But apart from what it's *not*, I'm not really sure
what it actually *is* yet. So, when looking at the question: "If you have
to replace the early stages of the bootstrapping" - as of now I can only
answer: uhmmm, do I? :/ Can someone please help me understand how can I
recognize if I have to [replace gcc in the early stages of bootstrapping]
here, or not? :/
As to the second paragraph, I'm afraid I'm now even more confused... the
first para mentions "the overlay system doesn't allow to [replace gcc] in
early stages of bootstrapping"; but then the second para mentions: "overlay
should help you [...] by replacing [...] all the packages used by
bootstrapping". So, does it mean that an overlay cannot replace gcc while
bootstrapping, but can replace other packages? Or does this mean something
else? There's probably some nuance I cannot grasp at work here?...
To explain myself a bit as to why I'm asking about overlays at all, my
question originally was kind of a wild shot that maybe when building my
"l4linux.nix" standalone expression, which I usually would start as:
```nix
with import <nixpkgs> {};
# ...
```
I could maybe replace the gcc in the <nixpkgs> by doing something like:
```nix
with import <nixpkgs> { overlays = { gcc =
.../*somehow-gcc6-with-patch*/...; }; };
# ...
```
and this way benefit from reusing various intermediate stuff already
defined in <nixpkgs>. But I think I'm slowly starting to come to terms with
an intuition, that probably maybe forking <nixpkgs> may be an easier and
more straightforward way for me to start with. Trying to refactor this to a
standalone Nix expression may be possibly better left for me as a follow up
goal, once I have the stuff done the uglier but simpler way.
Other than that, I'll certainly try to analyze the sources at the provided
links, and try to find out if I can understand more from them. Thanks!
/Mateusz.
On Fri, May 26, 2017 at 1:29 PM, Nicolas Pierron <nicolas.b.pier...@nbp.name
> wrote:
> Hi,
>
> You can indeed replace gcc by a newer version of it, but the overlay
> system does not allow you to do so inside the early stages of the
> bootstrapping. If you have to replace the early stages of the
> bootstrapping, then I suggest you look at `pkgs/stdenv/default.nix`
> and `pkgs/stdenv/linux/default.nix` and give it as argument of
> `pkgs/top-level/default.nix` which is currently loading this file to
> bootstrap the standard environment.
>
> Otherwise, an overlay should help you with what you are looking for by
> replacing the `stdenv` attribute as well as all the packages used for
> bootstrapping. You have to replace these packages as well because you
> would otherwise have an inifnite loop as you try to add the new
> compiler to the stdenv, which would be needed for compiling the
> compiler it-self, due to `callPackage` taking stdenv from `self.`
>
> ```nix
> self: super:
>
> let
> ...
> stdenv = super.stdenvAdapters.overrideCC super.stdenv ...; # see [1]
> in
>
> { inherit stdenv; } // stdenv.overrides self super
> ```
>
> I did something similar a while ago, to use an old version of gcc, in
> order to reproduce a bug which was on a different CI. You can find
> the detail here[1].
> Note that, you might have to override the stdenv argument (and maybe
> others) used for building the compiler:
>
> ```nix
> cc.override { stdenv = super.stdenv }
> ```
>
> In addition to changing the source of the derivation, otherwise you
> might have an infinite loop, as the compiler is by default compiled
> with the `callPackage` function which takes its inputs from the result
> of the fix-point, which is not what you want here for bootstrapping
> this new stdenv for every packages.
>
> About making it a cross compiler, I do not know enough, but I can only
> give you some pointers to `makeStdenvCross` stdenv adapter
> function[2].
>
> I have not tested this for replacing the stdenv globally, but I think
> this will bring you closer to the final solution.
> Good luck.
>
> [1] https://github.com/mozilla/nixpkgs-mozilla/blob/master/release.nix#L96
> [2] https://github.com/NixOS/nixpkgs/blob/master/pkgs/
> stdenv/adapters.nix#L59
>
>
> On Wed, May 24, 2017 at 12:15 AM, Mateusz Czaplinski
> <czapko...@gmail.com> wrote:
> > I'm writing a local (non-nixpkgs) derivation, and I'd like to replace the
> > default "gcc" to be a patched gcc6 - also for all implicit dependencies
> in
> > nixpkgs. Is it possible to do that (I assume via overlays and resulting
> > fixpoint)? If yes, how should I write this to work?
> >
> > For background: I want to cross-compile the Linux kernel (actually, a
> fork -
> > L4Linux) to a new target platform. But setting `crossSystem` seems to
> > trigger rebuilding of gcc, which crashes on me because of OOM killer on
> > genattrtab. This I believe could be mitigated by a Nov'2016 patch to gcc
> > (https://patchwork.ozlabs.org/patch/695293/), so I believe I need to
> have it
> > incorporated into default gcc. This I hope would let me overcome the
> "out of
> > memory" obstacle, so that I could go back to hacking on my main task...
> >
> > When fixing this, I would much prefer not to have to fork whole nixpkgs,
> if
> > feasible. I suppose maintaining a nixpkgs fork is harder, and also
> sharing
> > sounds not so simple then as in the basic case of a single .nix file?
> >
> > I'd be grateful for any help.
> > Thanks,
> > /Mateusz.
> >
> > _______________________________________________
> > nix-dev mailing list
> > nix-dev@lists.science.uu.nl
> > https://mailman.science.uu.nl/mailman/listinfo/nix-dev
> >
>
>
>
> --
> Nicolas Pierron
> http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
>
_______________________________________________
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev
