Otherwise, when building glibc and other packages, the "strip" from
bootstrapTools is used, which doesn't recognise some tags produced by
the newer "ld" from binutils.
Fixes#12632.
I think it's better to quote this variable in general, because it is
common and even documented to pass space-separated commands in there.
The greps should just fail in that case and `if` won't proceed
which seems fine for such cases, and it's certainly better than
passing additional unintended parameters to grep
(which was happening all the time before).
Doing it in an openssl setup hook only works if packages have openssl
as a build input - it doesn't work if they're using a program linked
against openssl.
Commit 6d928ab684 changed this to not
preserve timestamps. However, that results in non-determinism; in
particular, it gives us a broken $SOURCE_DATE_EPOCH (especially for
everything using fetchFromGitHub). Builds affected by timestamps <
1980 should be fixed in some other way (e.g. changing the timestamp to
some fixed date > 1980).
This is used by some build tools to provide reproducible builds. See
https://reproducible-builds.org/specs/source-date-epoch/
for more info.
Later, we'll want to set this to a more intelligent value (such as the
most recent mtime of any source file).
So far if no configure script is found or no makefile,
the rest of the phase is skipped, *including* post-hooks.
I find that behavior unexpected/unintuitive.
Earlier version of this patch had problems due to me assuming
that $configureScript is always a simple path, but that turned out
to be false in many cases, e.g. perl.
The most complex problems were from dealing with switches reverted in
the meantime (gcc5, gmp6, ncurses6).
It's likely that darwin is (still) broken nontrivially.
Now development stuff is propagated from the first output,
and userEnvPkgs from the one with binaries.
Also don't move *.la files (yet). It causes problems, and they're small.
- there were many easy merge conflicts
- cc-wrapper needed nontrivial changes
Many other problems might've been created by interaction of the branches,
but stdenv and a few other packages build fine now.
- IMO using a temporary is not needed here (anymore),
- temporary at that location can cause a problem (in a specific case):
for example, when using the substituteAll function from nixpkgs
on a single file directly under /nix/store/ (or ./foo-file),
the stdenv's substitute tries to create a temporary directly under
/nix/store, which causes problems on chrooted darwin
(according to @copumpkin earlier today on IRC)
Getting the names of all environment variables is tricky. The previous
implementation easily got confused by multi-line variables. The new
one is more reliable but not still not perfect.
This works around a segfault in Bash 4.3, where the expression
"${!var}" (where var="-9") crashes under certain conditions.
http://hydra.nixos.org/build/16693445
Otherwise, stdenv won't have a reference to e.g. patchelf on Linux
(because it was passed in by mkDerivation). This causes the installer
tests to fail, because having "stdenv" in the installation CD closure
is not enough to pull in all stdenv packages.
http://hydra.nixos.org/build/16546643
Now it should contain *all* information from stdenv/setup.sh of
the original mutiple-output branch.
However, the configurability of the output paths is much greater.
This is needed for multiple-output derivations,
where it is desirable to propagate deps and setup-hooks into $dev instead of $out.
Also drop an unused simple function which will not even make sense.
Now gcc is just another build input, making it possible in the future
to have a stdenv that doesn't depend on a C compiler. This is very
useful on NixOS, since it would allow trivial builders like
writeTextFile to work without pulling in the C compiler.
If $src refers to a directory, then always copy it. Previously, we
checked the extension first, so if the directory had an extension like
.tar, unpackPhase would fail.
If a build input is a regular file, use it as a setup hook. This makes
setup hooks more efficient to create: you don't need a derivation that
copies them to $out/nix-support/setup-hook, instead you can use the
file as is.
You can now register multiple values per named hook, e.g.
addHook preConfigure "echo foo"
addHook preConfigure "echo bar"
will cause ‘runHook preConfigure’ to run both ‘echo foo’ and ‘echo
bar’ (in that order). It will also call the shell function
preConfigure() or eval the shell variable $preConfigure, if
defined. Thus, if you don't call addHook, it works like the old hook
mechanism.
Allowing multiple hooks makes stdenv more modular and extensible. For
instance, multiple setup hooks can define a preFixup hook, and all of
these will be executed.
setup.sh uses the anti-pattern `for f in $(find ...); do` in several
places. `find` returns one path per line, but `for` splits its arguments
by words, so paths which contain spaces are incorrectly split! The
correct way is `find ... | while read f; do`
Treating fixupPhase specially is really ugly. Also, it collides with
the work in the multiple-outputs branch (which already has support for
fixing up all outputs).
Partial revert of 0a44a09121.
Some programs, e.g. guile-config, has a shebang that ends in '\':
#!/usr/bin/guile-1.8 \
-e main -s
!#
;;;; guile-config --- utility for linking programs with Guile
;;;; Jim Blandy <jim@red-bean.com> --- September 1997
This currently breaks patchShebangs:
$ read oldPath arg0 args <<< 'shebang \'; echo $?
1
$ echo $oldPath
shebang
$ echo $arg0
$ echo $args
(And setup.sh/patchShebangs is run with 'set -e' so any command that
return non-zero aborts the build.)
Fix by telling 'read' to not interpret backslashes (with the -r flag):
$ read -r oldPath arg0 args <<< 'shebang \'; echo $?
0
$ echo $oldPath
shebang
$ echo $arg0
\
$ echo $args
Also needed: escape the escape characters so that sed doesn't interpret
them.
patchShebangs has a bug that shows itself on files that have the
executable bit set but have no shebang (i.e. a blank/empty first line).
The shell would then evaluate this:
if [ != '#!' ]; then
# not evaluated
fi
With proper quoting we get the correct behaviour:
if [ "" != '#!' ]; then
# this will be evaluated
fi
When building e.g. perl for the first time there is no perl in PATH yet,
so command -v perl will fail.
This brings back the previous behaviour of silently not patching
shebangs for which there is no available command in PATH.
Currently "/usr/bin/env python" is rewritten to "/nix/store/.../env
python". That doesn't really improve anything because the interpreter
still have to be located in $PATH at runtime. The result is that many
nix package expressions do .../bin/env fixup themselves.
Instead of everyone having to do this patching locally, add the
functionality to the standard environment patchShebangs function so that
everyone can benefit.
set CMAKE_LIBRARY_PATH, CMAKE_INCLUDE_PATH based on NIX_CFLAGS_COMPILE and
NIX_LDFLAGS so that cmake's find_library like functions find all the libraries
gcc knows about thanks to the gcc wrapper
This is particular useful with myEnvFun which then also sets those CMAKE_* env
variables.`
Because setup.sh has to change this causes many rebuilds - thus it should be
included in a stdenv-update like branch
Also cmake builds in parallel perfectly fine
update cmake to latest minor number, I didn't change the patches,
just reapplied them manually recordin a new patch
I'm not sure whether this was by intention, but so far postPatch hooks were
silently skipped whenever the patches list was empty. This change could possibly
change the build results of the following packages:
* gcc
* cmake (264)
* systemtap
* quemu-kvm
These packages all have in common that they have a postPatch hook and the
patches list can be empty when certain conditions are met.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is for consistency with terminology in stdenv (and the terms
"hostDrv" and "buildDrv" are not very intuitive, even if they're
consistent with GNU terminology).
This allows various applications. It allows users to set global
optimisation flags, e.g.
stdenv.userHook = ''NIX_CFLAGS_COMPILE+=" -funroll-loops"'';
But the impetus is as an alternative to issue #229, allowing impure
stdenv setup for people who want to use distcc:
stdenv.userHook = "source /my/impure/setup-script.sh";
This is probably a bad idea, but at least now it's a bad idea in
people's configuration and not in Nixpkgs. :-)
bash's pattern replacement feature. "replace-literal" is an
uncommon command so it was a headache during the bootstrap.
svn path=/nixpkgs/branches/stdenv-updates/; revision=31681
These markers follow the format of those of `nix-store --print-build-trace',
which allows extraction of, say, phase durations in a similar way.
svn path=/nixpkgs/branches/stdenv-updates/; revision=26115
If a build expressions has set "enableParallelBuilding = true", then the
generic builder may utilize more than one CPU core to build that particular
expression. This feature works out of the box for GNU Make. Expressions that
use other build drivers like Boost.Jam or SCons have to specify appropriate
flags such as "-j${NIX_BUILD_CORES}" themselves.
svn path=/nixpkgs/branches/stdenv-updates/; revision=22399
inputs did not get in)
Updating the xorg builder script to support cross building (in fact, support
for propagating the required build inputs).
svn path=/nixpkgs/branches/stdenv-updates/; revision=18569
- Before this changes, cflags and ldflags for the native and the cross compiler
got mixed. Not all the gcc-wrapper/gcc-cross-wrapper variables are
independant now, but enough, I think.
- Fixed the generic stdenv expression, which did a big mess on buildInputs and
buildNativeInputs. Now it distinguishes when there is a stdenvCross or not.
Maybe we should have a single stdenv and forget about the stdenvCross
adapter - this could end in a stdenv a bit complex, but simpler than the
generic stdenv + adapter.
- Added basic support in pkgconfig for cross-builds: a single PKG_CONFIG_PATH
now works for both the cross and the native compilers, but I think this
should work well for most cases I can think of.
- I tried to fix the guile expression to cross-biuld; guile is built, but not
its manual, so the derivation still fails. Guile requires patching to
cross-build, as far as I understnad.
- Made the glibcCross build to be done through the usage of a
gcc-cross-wrapper over the gcc-cross-stage-static, instead of using it
directly.
- Trying to make physfs (a neverball dependency) cross build.
- Updated the gcc expression to support building a cross compiler without getting
derivation variables mixed with those of the stdenvCross.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18534
derivation, the "buildInputs" in every stdenv mkDerivation don't map now
directly to the environment
variable "buildInputs" in the builder, but "buildNativeInputs". So, the inputs
build by the native compiler.
When cross compiling, they will map to the environment variable "buildInputs"
(yes, now the same name), which means does to be built with the cross compiler.
I think I improved the naming of variables a bit. There was a big mess,
specially in the stdenv adapter for cross building, and also in the default
builder script.
I also tried to add proper manager of propagatedInputBuilds, these being
propagated considering the host or build origin of that input build (so, at the
end, being those propagatedInputBuilds being propagated properly to the native
or the cross compiler.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18477
I made the stdenvCross adapter simpler, according to Nicolas Pierron comments,
and I commented it a bit.
There are still jobs to do. At least:
- Plan for the general renaming from buildInputs to hostInputs
- We should not break merges from trunk.
- Make the generic stdenv understand about host/buildInputs, at least for
native builds, because it is used in the always-native building of
stdenvLinux. This should allow us to remove all duplications of "*NoCross" in
nixpkgs.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18449
* setup.sh: removed some obsolete features, specifically some that
were only used by the old build farm.
* addToSearchPath: removed some parameters that weren't used
anywhere.
svn path=/nixpkgs/branches/stdenv-updates/; revision=15136
instead of "gcc-4.3.3". This fixed the long-standing annoyance that
you can't distinguish the two in (say) nix-store -qR.
* On x86_64-linux, put $out/lib64 in the RPATH in addition to
$out/lib, because some packages (in particular GCC) put libraries in
$out/lib64 and ended up linking against the wrong library.
* Strip $out/lib64.
* Removed g77_42 because it's exactly the same as gfortran.
svn path=/nixpkgs/branches/stdenv-updates/; revision=14708
variables. This is so you don't have to write things like
preBuild=preBuild
preBuild() {
bla
}
svn path=/nixpkgs/branches/stdenv-updates/; revision=13941
paths. E.g. /usr/bin/perl is rewritten to /nix/store/<whatever Perl
is in $PATH>. Paths in the Nix store are left unchanged.
Contributed by Nicolas Pierron.
svn path=/nixpkgs/branches/stdenv-updates/; revision=12036
the fail() function unnecessary.
* Flag showBuildStats to print execution times on builder exit.
svn path=/nixpkgs/branches/stdenv-updates/; revision=11688
* Updated the kernel headers.
* ghc: setup hooks are now generated using substituteAll.
svn path=/nixpkgs/branches/stdenv-updates-merge/; revision=10838
stack traces impossible.
* When stripping all symbols on Darwin, don't use the "-s" flag
since it has a completely different meaning (it takes an argument
specifying a file containing a list of symbols).
svn path=/nixpkgs/branches/stdenv-updates-merge/; revision=10809
merge cleanly right away (kde-4, kernel stuff) so it should be
merged later. But the stdenv stuff is all there.
svn path=/nixpkgs/branches/stdenv-updates-merge/; revision=10793
