--On 14 janvier 2013 22:43:39 + Sander van der Burg - EWI
wrote:
> It's possible to use the Nix package manager on Mac OS X. I'm using it
> quite frequently these days at work (although I don't own any Apple
> devices myself :-) ). However, Mac support is less mature and the
> packages colle
Florian Friesdorf writes:
> > I don't think this is related in any way at all to your patch or to
> > the python branch, but it's pretty effective at preventing me from
> > building numpy.
>
> The python branch is based on a rather recent trunk. You could try to
> apply the patch to nixpkgs
Florian Friesdorf writes:
> Could you try whether the attached patch also solves building on OS X
> (Konrad) and whether matplotlib builds for you (Peter)?
Since I recently upgraded to MacOS X 10.7, I decided to reinstall Nix (1.0)
and Nixpkgs from scratch to see how it works out. I downloaded
Michael Raskin writes:
> Well, the inner workings of Nix being undocumented is incorrect - for
> example, Eelco Dolstra wrote a PhD thesis where this topic is nicely
> covered...
Sander van der Burg - EWI writes:
> Eelco's PhD thesis explains more relevant concepts that you may
> want to kn
I just posted an article about Nix on my blog:
https://khinsen.wordpress.com/2012/05/14/the-nix-package-manager-in-computational-science/
I'd appreciate any feedback, in particular if anything I wrote there is not
correct.
Konrad.
___
nix-dev maili
Peter Simons writes:
> > Building NumPy on MacOS fails with the current state of nixpkgs, and I
> > suspect it can fail on other platforms as well, as the problems I found
> > are not specific to MacOS. With the attached patch, it builds correctly,
> > at least under MacOS.
>
> I applie
Building NumPy on MacOS fails with the current state of nixpkgs, and I
suspect it can fail on other platforms as well, as the problems I found are
not specific to MacOS. With the attached patch, it builds correctly, at
least under MacOS.
Konrad.
numpy.patch
Description: Binary data
_
On 26 avril 2012 01:18:02 +0200 Ludovic Courtès wrote:
>> And did you try after r33911? This commit sets ‘noSysDirs’ to false
>> on Darwin, meaning that GCC would look for files under /usr (stdenv.gcc
>> already did that.)
>
> Ah, that's what's missing then. I used r33899. I will update and try
--On 26 avril 2012 01:18:02 +0200 Ludovic Courtès wrote:
>>> ~/.nix-profile/bin/gcc hello.c -o hello
>> hello.c:1:19: fatal error: stdio.h: No such file or directory
>> compilation terminated.
>
> Hmm, how did you install it?
nix-env -i -f path/to/nixpkgs -A gcc46
> And did you try after r33911
Ludovic Courtès writes:
> > It's difficult not to have anything in /usr/local, since Nix installs
> > itself there as well. But I did remove GMP plus some stuff that depended on
> > it (gpmc, mpfr), and now gcc46 compiles to the end, in just a few hours.
>
> Good!
One more question about gc
Ludovic Courtès writes:
> Can you remove GMP from /usr/local?
>
> It’s generally a bad idea to have software available there on Hydra,
> because then packages built with Nix may end up using them, leading to a
> complete mess of impurity as the rest of the world knows it. :-)
MacPorts for
Ludovic Courtès writes:
> Here we are! ‘stdenvNative’ on Darwin now uses GCC 4.6, like on all the
> other platforms. The Darwin-specific tools (‘arch’, ‘sw_vers’, etc.)
> are now part of ‘stdenv’ as well, and ‘darwinArchUtility’ & co. are gone.
>
> Let me know if there’s anything wrong!
S
Ludovic Courtès writes:
> The attached patch incorporates all these changes.
I tried to install gcc46 after applying your patches. stdenv builds fine, but
mpfr (a dependency of gcc46) fails at the link stage:
ld: pointer in read-only segment not allowed in slidable image, used in
___gmpn_div
--On 17 avril 2012 14:25:18 +0200 Ludovic Courtès
wrote:
> It turns out that getting GCC 4.6 to build on Darwin wasn’t so
> difficult. The patch below fixes that, by adding lipo(1) to stdenv.
> However, since it modifies stdenv, it entails a full rebuild.
>
> Would it be a problem for you? Wha
Ludovic Courtès writes:
> I had noticed it too. Actually, ‘stdenv’ on Darwin builds fine because
> it uses ‘noSysDirs = false’ somehow, so the faulty patch didn’t get
> applied.
>
> Anyway, I just fixed ‘no-sys-dirs.patch’ so that it actually applies.
Great. I think I got to the same point
I made some progress in getting gcc installed under MacOS, but at some
point compilation fails because stdio.h and some other header files
are not found. I ran "find /nix/store -name stdio.h" to see where it
should come from, but found only this:
/nix/store/88bjkrhrgsc4gb4z7ay710j6m5mv2mg0-gcc-app
Rob Vermaas writes:
> > > It tell you the moment a build fails. E.g.
> >
> > Not for me:
> >
...
> Are you sure you are not using -k (lower case, which actually means
> keep-going) ?
No, I am not sure. Coming back to my Nix experiments after a few days' break,
I can't reproduce what I saw
I have made some progress analyzing the build failures with gfortran I
see under 64-bit MacOS X.
The derivation whose build fails is gcc-apple-4.2.1.5666.3. I have the
basic version (no Fortran etc.) installed from the nix_unstable as a
binary, but when I request gfortran, it is built again with l
Rob Vermaas writes:
> Hi Konrad,
>
> > > $ nix-env --help
> > > ...
> > > --keep-failed / -K: keep temporary directories of failed builds
> >
> > Thanks! nix-build understand the same option. But what it doesn't do
> > is tell me where the temporary directory actually is. I ended up
Rob Vermaas writes:
> > For now, I am still stuck in figuring out why gfortran won't build on
> > my MacOS X system. Is there a way to prevent nix-build from deleting
> > its temporary work directory if the build fails? Seeing its state at
> > the point of failure would help me to analyse the
Daniel Santa Cruz writes:
> It would we awesome if you posted something once you have a process in
> place. I find
> that there is a need for that kind of information.
I keep notes as I progress, so that should be if I ever get to the
point of having a working nixpkgs installation.
For now,
Michael Raskin writes:
> Changes to NixPkgs tree do not affect the packages built from it; and it
> is version-controlled, so you can revert if you make a mistake.
>
> nix-call-package script allows me to test most of the new packages
> without adding them to all-packages.nix
>
> I don'
Konrad Hinsen writes:
> While trying to build some derivations for MacOSX, I hit a problem
> which I think is a bug in nixpkgs and which moreover I think I know
> how to fix. How would I best go about debugging this? Can I just
> copy the source code somewhere, modify some fil
Peter Simons writes:
> in the past, we have dealt with these kind of problems by passing lipo
> explicitly to those expressions that need it. The 'mesa' expression, for
> example, takes the following argument:
>
> lipo = if stdenv.isDarwin then darwinLipoUtility else null;
That's fine as
While trying to build some derivations for MacOSX, I hit a problem
which I think is a bug in nixpkgs and which moreover I think I know
how to fix. How would I best go about debugging this? Can I just
copy the source code somewhere, modify some files, and then test-build
and test-run with that modif
Florian Friesdorf writes:
> It should be:
>
> $ nix-env -iA nixpkgs_unstable.pythonPackages.numpy
OK, that one works fine :-)
I also figured out how to get these full names:
nix-env -qaP '*'
I'll stick to full names, that should get me out of a lot of trouble.
> nix-env -qa \* |grep f
Eelco Dolstra writes:
> Thanks, I've fixed this. The problem was that Nixpkgs also contains packages
> for Python 2.6 (the python26Packages attribute in all-packages.nix). So if
> you
OK, that explains everything.
> It's always possible to disambiguate by using the -A flag to select a
>
I am starting to explore the nixpkgs collection and I wonder if there is a
way to see the Nix expressions that correspond to the current state of the
channel nixpkgs-unstable, in order to understand exactly what's going on
when packages are installed.
My first idea was to use the Subversion reposi
Eelco Dolstra writes:
> What does "nix-env -qas hello" show? It should show something like
>
> $ nix-env -qas hello
> --S hello-2.7
>
> If the "S" is missing, it means it doesn't know about the pre-built binaries
> in
> the Nixpkgs channel for some reason. Check if there is something
Hi everyone,
I have just started to look at Nix seriously, which means first of all
trying to get it to work. I started with nix-0.16, which I installed
on my Mac running under MacOS X 10.6.8. No problem at all with the installation,
and subscribing to nixpkgs-unstable seemed to work fine as well.
30 matches
Mail list logo
