[Nix-dev] Boost postFixup failing

[zimbatm]

Ok system memory is probably not the issue with 16GB, maybe it's the
process itself who has some sort of ulimit. The next step would be to try
to graph memory usage over time.

Yes as long as the source and the target are on the same architecture you
can use nixops easily. I think otherwise you'll require a remote builder.

On Thu, 20 Oct 2016, 22:12 Ashley Gillman, <gillwoman at gmail.com> wrote:

> Thanks Zimbatm,
> 16GB, and I retried with 32GB.
>
> Actually a very good idea with NixOps. I didn't realise you could use your
> own pre-built stuff, that would really simplify things. As a data scientist
> I am not so familiar with DevOps but it might be just the solution to get
> the reproducibility I need. Guess I have my weekend project sorted :)
>
> Cheers,
> Ash
>
>
> > On 21 Oct 2016, at 3:47 am, zimbatm <zimbatm at zimbatm.com> wrote:
> >
> > How much memory do you have available? 16MB is just for this process,
> nix-env itself is probably taking another 200MB or more.
> >
> > One solution is to build things locally and then use nix-copy-closure or
> nixops to deploy the changes.
> >
> >
> > On Thu, 20 Oct 2016, 13:55 Ashley Gillman, <gillmanash at gmail.com> wrote:
> > Hi Nix Dev,
> >
> > I am having issues installing on an HPC cluster. My methodology has been
> using PRoot to mount a directory to /nix. I am using Nix 1.11.2
> >
> > Impurities seem to be creeping into the build process, that I don't get
> when building locally. For example, when building Python Pillow, I had to
> also mount an empty directory over /usr/include, because the builds were
> including gcc flags for `-I/usr/include` and breaking the build. But this
> shouldn't happen, should it? The hack of mounting over these directories
> was a temporary fix.
> >
> > My current error is when building Boost with GCC49, which again works
> locally (Ubuntu 14.04) but not on the cluster.
> >
> >     nix-build -E 'with import <nixpkgs> { }; boost.override { stdenv =
> overrideCC stdenv gcc49; }'
> >     ...
> >     post-installation fixup
> >     shrinking RPATHs of ELF executables and libraries in
> /nix/store/fv2wsfc1g43m72xy0398lh8wgi6nsx1z-boost-1.59.0
> >     gzipping man pages in
> /nix/store/fv2wsfc1g43m72xy0398lh8wgi6nsx1z-boost-1.59.0
> >     patching script interpreter paths in
> /nix/store/fv2wsfc1g43m72xy0398lh8wgi6nsx1z-boost-1.59.0
> >     shrinking RPATHs of ELF executables and libraries in
> /nix/store/sgs6pcdj7c3xkmvh0s51hvs06ahan50l-boost-1.59.0-dev
> >     /nix/store/nkl8p82samb219yr5i7bdx4mm2mgg5ab-stdenv/setup: xmalloc:
> subst.c:4911: cannot allocate 256 bytes (16777216 bytes allocated)
> >     builder for
> ‘/nix/store/xqsq53xim1kbhk4zsdimmjxwc9s13n3b-boost-1.59.0.drv’ failed with
> exit code 2
> >
> > This looks like a memory error, but for 16MB? I certainly have much more
> memory than that available, and increasing the allocated memory for the
> compute nodes doesn't change the error. I am guessing it may be again due
> to some impurity, how can these creep in?
> >
> > Any advise, even on how best to debug, is much appreciated.
> >
> > Kind regards,
> > Ashley
> > _______________________________________________
> > nix-dev mailing list
> > nix-dev at lists.science.uu.nl
> > http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.science.uu.nl/pipermail/nix-dev/attachments/20161021/7ea6c80d/attachment.html>