2003-11-04 09:36:52 +01:00
|
|
|
{pkgs}: [
|
|
|
|
|
pkgs.coreutils
|
|
|
|
|
pkgs.findutils
|
|
|
|
|
pkgs.diffutils
|
|
|
|
|
pkgs.gnused
|
|
|
|
|
pkgs.gnugrep
|
|
|
|
|
pkgs.gawk
|
|
|
|
|
pkgs.gnutar
|
|
|
|
|
pkgs.gzip
|
2015-04-18 19:32:52 +02:00
|
|
|
pkgs.bzip2.bin
|
2003-11-04 09:36:52 +01:00
|
|
|
pkgs.gnumake
|
2003-11-05 13:17:48 +01:00
|
|
|
pkgs.bash
|
2004-09-18 19:12:30 +02:00
|
|
|
pkgs.patch
|
2014-08-26 00:17:03 +02:00
|
|
|
pkgs.xz.bin
|
fixLibtool(): patch ./configure, add `file` to common-path.nix
libtool's libtool.m4 script assumes that `file` is available, and can
be found at `/usr/bin/file` (this path is hardwired). Furthermore,
the script with this assumption is vendored into the ./configure
scripts of an enormous number of packages. Without this commit, you
will frequently see errors like this during the configurePhase with
the sandbox enabled:
./configure: line 9595: /usr/bin/file: command not found
Due mostly to luck, this error does not affect native compiles on
nixpkgs' two most popular platforms, x86_64-linux and aarch64-linux.
However it will cause incorrect linker flag detection and a failure to
generate shared libraries for sandboxed cross-builds to a x86_64-linux
host as well as any sandboxed build (cross or native) for the following
hosts: x86_64-freebsd, *-hpux, *-irix, mips64*-linux, powerpc*-linux,
s390x-linux, s390x-tpf, sparc-linux, and *-solaris.
This commit fixes the problem by adding an extra line to fixLibtool()
in pkgs/stdenv/generic/setup.sh. This extra line will scan the
unpacked source code for executable files named "configure" which
contain the following text:
'GNU Libtool is free software; you can redistribute it and/or modify'
This text is taken to be an indicator of a vendored libtool.m4. When
it is found, the configure script containing it is subjected to `sed
-i s_/usr/bin/file_file_` which replaces all occurrences of
`/usr/bin/file` with `file`.
Additionally, the `file` package is now considered to be part of
`stdenv`. It has been added to `common-path.nix` so that the `file`
binary will be found in the `$PATH` of every build, except for the
bootstrap-tools and the first few stages of stdenv boostrapping.
Verified no regressions under:
nix-build --arg pkgs 'import ./. {}' ./lib/tests/release.nix
This commit allows the following commands to complete, which should
enable Hydra to produce bootstrap-files for mips64el:
nix-build \
--option sandbox true \
--option sandbox-fallback false \
pkgs/top-level/release-cross.nix \
-A bootstrapTools.mips64el-linux-gnuabi64.build
nix-build \
--option sandbox true \
--option sandbox-fallback false \
. \
-A pkgsCross.mips64el-linux-gnuabi64.nix_2_4
2022-04-12 23:46:57 +02:00
|
|
|
|
|
|
|
|
# The `file` command is added here because an enormous number of
|
|
|
|
|
# packages have a vendored dependency upon `file` in their
|
|
|
|
|
# `./configure` script, due to libtool<=2.4.6, or due to
|
|
|
|
|
# libtool>=2.4.7 in which the package author decided to set FILECMD
|
|
|
|
|
# when running libtoolize. In fact, file-5.4.6 *depends on itself*
|
|
|
|
|
# and tries to invoke `file` from its own ./configure script.
|
|
|
|
|
pkgs.file
|
2003-11-04 09:36:52 +01:00
|
|
|
]
|
