Glibc. This is useful when building GCC.
* gcc-wrapper: the dynamic linker has a different name on x86_64 and
powerpc.
* gcc-wrapper: "glibc" -> "libc", because someday we might support
different C libraries.
* gcc: don't do a multilib build (e.g., 32-bit support on x86_64),
don't need it.
* gcc: merge in support for static builds.
* gcc: various simplifications in the compiler/linker flags, hope they
work.
svn path=/nixpkgs/trunk/; revision=6823
contains arbitrary information about a package, like this:
meta = {
homepage = "http://gcc.gnu.org/";
license = "GPL/LGPL";
description = "GNU Compiler Collection, 4.0.x";
};
The "meta" attribute is not passed to the actual derivation
operation, so it's not a dependency --- changes to "meta" attributes
don't trigger a recompilation.
Now we have to standardise some useful attributes ;-)
svn path=/nixpkgs/branches/usability/; revision=5024
Even though you could just inherit binutils it is conceptually cleaner (I
think) to make these tools available here.
svn path=/nixpkgs/trunk/; revision=4967
* added an experimental fetchdarcs function, based on fetchsvn
(there are no expressions yet that use this function)
svn path=/nixpkgs/trunk/; revision=4615
in /usr/lib/libGL.so.1 (which will typically load a driver in
/usr/X11R6/lib/modules/dri). This has been tested on a i915
graphics card; it should work with most open source X.org drivers.
For NVidia's proprietary drivers (which we cannot build ourselves
anyway), some more symlinks are necessary; I'll add those later.
So to get hardware-accelerated Quake 3, do:
$ nix-env -p /nix/var/nix/profiles/opengl -i xorg-sys-opengl
$ nix-env -i quake3-demo
$ quake3
svn path=/nixpkgs/trunk/; revision=4613
allow the OpenGL implementation to be overriden through the
OPENGL_DRIVER environment variable. If it is not set, we use the
implementation installed in the profile
/nix/var/nix/profiles/opengl, allowing easy late binding by the
user, e.g.,
$ nix-env -p /nix/var/nix/profiles/opengl -i nvidia-sys-opengl
might install the NVidia OpenGL implementation.
The code that does this is not specific to Quake 3: it has been
factored out into build-support/opengl/mesa-switch.sh. Presumably
any application that requires hardware-accelerated OpenGL needs it.
* Add the Quake 3 demo to the cache.
svn path=/nixpkgs/trunk/; revision=4612
server's certificate. This is perfectly safe: we don't care whether
the server is being spoofed --- only the cryptographic hash of the
output matters.
svn path=/nixpkgs/trunk/; revision=4377
right thing. This is necessary to make libtool detect g++
properly. (Fixes the `libtool: compile: unable to infer tagged
configuration' error on FreeBSD when building Berkeley DB 4.4.)
svn path=/nixpkgs/trunk/; revision=4370
* Use the system Perl on all non-i686-linux platforms.
* Don't build Python support in libxml2 on most platforms.
svn path=/nixpkgs/trunk/; revision=3019
`*.dll.config' files corresponding to CLR assemblies. I.e., the
full path to native libraries is included in the maps. In effect
this allows us to set the equivalent of an RPATH for assemblies.
* gtk-sharp: use the DLL fixer. It's not perfect yet: I still have to
set the LD_LIBRARY_PATH for monodoc to include the gtk-sharp lib
directory itself, so that it can find the `*sharpglue.so' files.
This seems to be gtk-sharp's fault; it doesn't have an entry for
those libraries in its DLL maps.
svn path=/nixpkgs/trunk/; revision=2330
this contains mostly Armijn's pure stdenv-linux.
* After unpacking the statically linked GCC, patch all store paths to
/nix/store/ffffffffffffffffffffffffffffffff. Ugly hack to prevent
undeclared references but it works.
* We don't need Glib's dynamic libraries in the first bootstrap stage;
delete them. Actually the downloaded Glibc binary is only needed
for building Glibc, since GCC needs a C compiler to build some
programs in `configure'. So static linking is fine for that. Maybe
it would be better to patch `configure' so that we don't need a
pre-built Glibc at all.
* Set the svn:executable property on `cp' and `patchelf'.
* In Glibc, revert to LinuxThreads. Maybe NPTL will work, but TLS
support is a problem.
* Delete most Glibc patches; they're no longer needed since the branch
updated it to 20050110.
* Some cleanups.
svn path=/nixpkgs/trunk/; revision=2258
files easier. Examples:
substitute inputFile outputFile \
--replace "@bindir@" "$out/bin" \
--replace "@gcc@" "$GCC/bin/gcc"
substitute inputFile outputFile --subst-var out
(this is sugar for --replace "@out@" "$out")
substituteInPlace file --replace a b
(input and output are both `file'; the execute bit is preserved)
svn path=/nixpkgs/trunk/; revision=2239
the tree being fetched from a Subversion repository. The revision
number is now optional (and defaults to HEAD).
This makes `fetchsvn' more pure. First, a URL/revision tuple does
not uniquely identify a file resource, since the repository itself
might change. Second, `svn:external' attributes can cause arbitrary
resources to be exported.
A script `nix-prefetch-svn' has been provided to determine the hash
of a URL.
svn path=/nixpkgs/trunk/; revision=938
libgcc of the gcc being built, not the gcc building it.
* Only include a directory in the rpath of an executable/library if it
is actually used. Before, the `/lib' directory of every build input
was added to the rpath, causing many unnecessary retained
dependencies. For instance, Perl has a `/lib' directory, but most
applications whose build process uses Perl don't actually link
against Perl. (Also added a test for this.)
* After building glibc, remove glibcbug, to prevent a retained
dependency on gcc.
* Add a newline after `building X' in GNU Make.
svn path=/nixpkgs/trunk/; revision=911
On the downside, the build process of stdenvLinux builds gcc 9 times
(3 x 3 bootstrap stages). That's a bit excessive.
svn path=/nixpkgs/trunk/; revision=880
* Make builders unexecutable by removing the hash-bang line and
execute permission.
* Convert calls to `derivation' to `mkDerivation'.
* Remove `system' and `stdenv' attributes from calls to
`mkDerivation'. These transformations were all done automatically,
so it is quite possible I broke stuff.
* Put the `mkDerivation' function in stdenv/generic.
svn path=/nixpkgs/trunk/; revision=874
builders for typical Autoconf-style to be much shorten, e.g.,
. $stdenv/setup
genericBuild
The generic builder does lots of stuff automatically:
- Unpacks source archives specified by $src or $srcs (it knows about
gzip, bzip2, tar, zip, and unpacked source trees).
- Determines the source tree.
- Applies patches specified by $patches.
- Fixes libtool not to search for libraries in /lib etc.
- Runs `configure'.
- Runs `make'.
- Runs `make install'.
- Strips debug information from static libraries.
- Writes nested log information (in the format accepted by
`log2xml').
There are also lots of hooks and variables to customise the generic
builder. See `stdenv/generic/docs.txt'.
* Adapted the base packages (i.e., the ones used by stdenv) to use the
generic builder.
* We now use `curl' instead of `wget' to download files in `fetchurl'.
* Neither `curl' nor `wget' are part of stdenv. We shouldn't
encourage people to download stuff in builders (impure!).
* Updated some packages.
* `buildinputs' is now `buildInputs' (but the old name also works).
* `findInputs' in the setup script now prevents inputs from being
processed multiple times (which could happen, e.g., if an input was
a propagated input of several other inputs; this caused the size
variables like $PATH to blow up exponentially in the worst case).
* Patched GNU Make to write nested log information in the format
accepted by `log2xml'. Also, prior to writing the build command,
Make now writes a line `building X' to indicate what is being
built. This is unfortunately often obscured by the gigantic tool
invocations in many Makefiles. The actual build commands are marked
`unimportant' so that they don't clutter pages generated by
`log2html'.
svn path=/nixpkgs/trunk/; revision=845
checked whether absolute paths passed to gcc/ld refer to the store,
which is wrong: they can also refer to the build tree
(/tmp/nix-...).
* Less static composition in the construction of stdenv-nix-linux:
gcc-wrapper and generic are now passed in as arguments, rather then
referenced by relative path. This makes it easier to hack on a
specific stage of the bootstrap process (before, a change to, e.g.,
generic/setup.sh would cause all bootstrap stages to be redone).
svn path=/nixpkgs/trunk/; revision=833
- gcc/ld-wrappers have been factored out into a separate
derivation. This allows a working gcc to be installed in the user
environment. (Previously the Nix gcc didn't work because it
needed a whole bunch of flags to point to glibc.)
- Better modularity: packages can specify hooks into the setup
scripts. For instance, setup no longer knows about the
PKG_CONFIG_PATH variable; pkgconfig can set it up instead.
- gcc not longer depends on binutils. This simplifies the bootstrap
process.
svn path=/nixpkgs/trunk/; revision=816
a big problem, so I decided to require to user to get the
file and put it in some location in the file system. wget
doesn't seem to accept the file scheme however, so I had to
move the copying into the builder itself. The builder checks
the md5 hash of the downloaded file. Maybe having a separate
'fetchfile' would be useful to make a file in the outside
world pure. I tried to add this to build-support, but this
obviously did not work. I still committed it. Just remove it
if you think that it sucks.
svn path=/nixpkgs/trunk/; revision=716
