On MacOS X, we used to use the native perl interpreter from /usr/bin.
Unfortunately, that interpreter fails to build a number of packages
(Subversion, Git, etc. ...), because it assumes knowledge about the
underlying C compiler that is not valid for the compiler used by Nix.
For example, /usr/bin/perl assumes that the compiler can build binaries
for both the ppc and the x86 architecture. /usr/bin/gcc can do that, but
the gcc from Nix can't.
The solution is to compile Perl 5.10 in Nix so that the ./configure
phase can properly detect the system's capabilities. However, note that
the resulting binary is impure: it will find headers in /usr/include and
libraries in /usr/lib. In this respect, the Nix-compiled perl binary is
no different than the native one in /usr/bin -- it's just configured
more accurately.
svn path=/nixpkgs/trunk/; revision=17870
buildDefs doesn't like buildInputs containing nulls.
* In all-packages.nix: xfsProgs -> xfsprogs, jfsUtils -> jfsutils to
match the upstream name.
svn path=/nixpkgs/trunk/; revision=17726
- Fixed location of the VirtualBox icon
- Removed qt3 as dependency of VirtualBox since it's obsolete since 3.0.x
svn path=/nixpkgs/trunk/; revision=17725
I had to use a newer patchelf (0.5), otherwise patchelf (0.4) died with an error at
setting the rpath for a lib.
("virtual address overrun" or something like that)
I still don't know of any stable url for a given version, so we will have this working
until they change the package file again updating.
svn path=/nixpkgs/trunk/; revision=17680
I don't know if the 'unfree' in the amr libraries will stop mplayer being built without its support. We would have to write the all-packages MPlayer expression different, in this case.
svn path=/nixpkgs/trunk/; revision=17635
On MacOS X, we used to use the native perl interpreter from /usr/bin.
Unfortunately, that interpreter fails to build a number of packages
(Subversion, Git, etc. ...), because it assumes knowledge about the underlying
C compiler that is not valid for the compiler used by Nix. For example,
/usr/bin/perl assumes that the compiler can build binaries for both the ppc and
the x86 architecture. /usr/bin/FCC can do that, but the gcc from Nix can't.
The solution is to compile Perl 5.10 via Nix so that it can properly configure
itself. However, note that the resulting binary is impure: it will find headers
in /usr/include and libraries in /usr/lib -- something a pure perl binary
wouldn't do. In this respect our Nix-compiled perl binary is not better than
the native one from /usr/bin -- it's just more accurately configured.
svn path=/nixpkgs/trunk/; revision=17618
