| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
I've had better luck creating statically-linked binaries that work than
dynamically-linked ones, so this is needed quite practically.
|
|
It rebuilt stdenv on *-darwin; we can't do that in nixpkgs master.
This reverts commit 2f20501c5f188ab0c4c430519ce77bc6b988202b, reversing
changes made to fd469c24af2e16aad2c2b4fc90fc8c74af36e773.
|
|
For a long time, we've had `crossLibcStdenv`, `*Cross` libc attributes,
and `*bsdCross` pre-libc package sets. This was always bad because
having "cross" things is "not declarative": the naming doesn't reflect
what packages *need* but rather how we *provide* something. This is
ugly, and creates needless friction between cross and native building.
Now, almost all of these `*Cross` attributes are gone: just these are
kept:
- Glibc's and Musl's are kept, because those packages are widely used
and I didn't want to risk changing the native builds of those at this
time.
- generic `libcCross`, `theadsCross`, and friends, because these relate
to the convolulted GCC bootstrap which still needs to be redone.
The BSD and obscure Linux or freestnanding libcs have conversely all
been made to use a new `stdenvNoLibc`, which is like the old
`crossLibcStdenv` except:
1. It usable for native and cross alike
2. It named according to what it *is* ("a standard environment without
libc but with a C compiler"), rather than some non-compositional
jargon ("the stdenv used for building libc when cross compiling",
yuck).
I should have done this change long ago, but I was stymied because of
"infinite recursions". The problem was that in too many cases we are
overriding `stdenv` to *remove* things we don't need, and this risks
cyles since those more minimal stdenvs are used to build things in the
more maximal stdenvs.
The solution is to pass `stage.nix` `stdenvNoCC`, so we can override to
*build up* rather than *tear down*. For now, the full `stdenv` is also
passed, so I don't need to change the native bootstraps, but I can see
this changing as we make things more uniform and clean those up.
Finally, the BSDs also had to be cleaned up, since they have a few
pre-libc dependencies, demanding a systematic approach. I realized what
rhelmot did in 61202561d92cf1cd74532fcbd8b9d6662c5bc57b (specify what
packages just need `stdenvNoLibc`) is definitely the right approach for
this, and adjusted NetBSD and OpenBSD to likewise use it.
|
|
|
|
|
|
|
|
The cc and bintools wrapper contained ad hoc bootstrapping logic for
expand-response-params (which was callPackage-ed in a let binding). This
lead to the strange situation that the bootstrapping logic related to
expand-response-params is split between the wrapper derivations (where
it is duplicated) and the actual stdenv bootstrapping.
To clean this up, the wrappers simply should take expand-response-params
as an ordinary input: They need an adjacent expand-response-params (i.e.
one that runs on their host platform), but don't care about the how.
Providing this is only problematic during stdenv bootstrapping where we
have to pull it from the previous stage at times.
|
|
We don't need to artificially make sure that we can execute the wrapper
scripts on the build platform by using stdenv's shell (which comes from
buildPackages) since our cross infrastructure will get us the wrapper
from buildPackages. The upside of this change is that cross-compiled
wrappers (e.g. pkgsCross.aarch64-multiplatform.gcc) will actually work
when executed!
For bootstrapping this is also not a problem, since we have a long
build->build platform chain so runtimeShell is just as good as
stdenvNoCC.shell. We do fall back to old ways, though, by explicitly
using the bootstrap-tools shell in stage2, so the adjacent bash is only
used from stage4 onwards. This is unnecessary in principle (I'll try
removing this hack in the future), but ensures this change causes zero
rebuilds.
|
|
`targetPlatform` and `hostPlatform` are already in scope, so it is
unnecessary to index into `stdenvNoCC`.
|
|
In delicate code like this, it seems unwise to pass something of as
something it isn't for convenience's (?) sake. It causes a slight
possibility for confusion with `buildPackages.stdenv`. However, it
should be possible to eliminate the need for this in a separate change.
|
|
|
|
This reverts commit b2844f89d10d4a2665aed231144950c354f275a6.
It broke simavr:
$ nix-build -A simavr
[...]
/nix/store/3k4djrsq23m2yg9ar4h1lkkz1ijv0ghv-avr-binutils-2.41/bin/avr-ld: /nix/store/3rpyzla18mbj690hv7j5dang0kd3c1fq-avr-libc-avr-2.1.0/avr/lib/libc.a(vfprintf_std.o): in function `.L15':
vfprintf.c:(.text.avr-libc+0xd8): undefined reference to `__mulqi3'
/nix/store/3k4djrsq23m2yg9ar4h1lkkz1ijv0ghv-avr-binutils-2.41/bin/avr-ld: /nix/store/3rpyzla18mbj690hv7j5dang0kd3c1fq-avr-libc-avr-2.1.0/avr/lib/libc.a(vfprintf_std.o): in function `.L18':
vfprintf.c:(.text.avr-libc+0xe4): undefined reference to `__mulqi3'
collect2: error: ld returned 1 exit status
make[1]: *** [../Makefile.common:161: atmega644_adc_test.axf] Error 1
make[1]: Leaving directory '/build/source/tests'
make: *** [Makefile:21: build-tests] Error 2
Fixes #295610.
|
|
|
|
This was moved in https://github.com/nixOS/nixpkgs/commit/1a5bd697adecf27385b69352485baa52a6e02fe9,
the preceding check was updated from hostPlatform to targetPlatform, but these got missed.
|
|
bintools-wrapper
this makes it a lot easier to create a modified stdenv with a
different set of defaultHardeningFlags and as a bonus allows us
to inject the correct defaultHardeningFlags into toolchain wrapper
scripts, reducing repetition.
while most hardening flags are arguably more of a compiler thing,
it works better to put them in bintools-wrapper because cc-wrapper
can easily refer to bintools but not vice-versa.
mkDerivation can still easily refer to either when it is constructed.
this also switches fortran-hook.sh to use the same defaults for
NIX_HARDENING_ENABLE as for C. previously NIX_HARDENING_ENABLE
defaults were apparently used to avoid passing problematic flags
to a fortran compiler, but this falls apart as soon as mkDerivation
sets its own NIX_HARDENING_ENABLE - cc.hardeningUnsupportedFlags
is a more appropriate mechanism for this as it actively filters
out flags from being used by the wrapper, so switch to using that
instead.
this is still an imperfect mechanism because it doesn't handle a
compiler which has both langFortran *and* langC very well - applying
the superset of the two's hardeningUnsupportedFlags to either
compiler's invocation. however this is nothing new - cc-wrapper
already poorly handles a langFortran+langC compiler, applying two
setup hooks that have contradictory options.
|
|
Fixed conflict in pkgs/applications/graphics/krita/
krita: 5.1.5 -> 5.2.0
7a40fdc288e69ba94947c1c4ec29c0f24e461eef
, and
treewide: use kde mirror everywhere, don't use pname in download urls
aa15f5066d695de4c4027bd8bdcf4cedcf58d058
|
|
-B must be set to the root directory of avrlibc, otherwise gcc cannot
locate crt objects for some attiny devices. -L trains as set by
bintools-wrapper are not necessary with -B set correctly because gcc
takes care of that, and likewise we can drop the -B train from
cc-wrapper because the one spec is enough.
|
|
|
|
fixes #245162
|
|
treewide: use optionalString instead of 'then ""'
|
|
|
|
|
|
lib.platforms.loongarch64: init
|
|
|
|
Most other bootstrap compilers are named -bootstrap so lets follow that
pattern.
|
|
{bintools,cc}-wrapper: don't fallback to version = null
|
|
mkDerivation cannot handle that
|
|
The motivation behind this is to alleviate the problem
described in https://github.com/NixOS/nixpkgs/issues/41340.
I'm not sure if this completely fixes the problem, but it
eliminates one more area where we can exceed command line
length limits.
This is essentially the same change as in #112449,
except for `ld-wrapper.sh` instead of `cc-wrapper.sh`.
However, that change alone was not enough; on macOS the
`ld` provided by `darwin.cctools` fails if you use process
substitution to generate the response file, so I put up a
PR to fix that:
https://github.com/tpoechtrager/cctools-port/pull/131
… and I included a patch referencing that fix so that the
new `ld-wrapper` still works on macOS.
|
|
|
|
not all linkers have a ld binary in bin
also note the '${ld:-}' which allows users to set the ld path with a env
var
> '${foo:-val}' $foo, or val if unset (or null)
|
|
allows using wrapBintoolsWith with all linkers
```
$ nix build ".#binutils"
$ ls ./result/bin/ld*
./result/bin/ld* ./result/bin/ld.bfd* ./result/bin/ld.gold*
$ nix build "nixpkgs#binutils"
$ ls ./result/bin/ld*
./result/bin/ld* ./result/bin/ld.bfd* ./result/bin/ld.gold*
```
|
|
|
|
|
|
|
|
For reasons explained in the commit contents, in order to build the
native gnat package for x86_64-darwin, the native gnatboot package for
x86_64-darwin must have access to both the Clang integrated assembler
and the cctools GNU assembler for that platform. This commit creates a
package with both of those assemblers that x86_64-darwin gnatboot can
then be wrapped with.
|
|
|
|
derivations can be coerced to their output paths
|
|
Co-authored-by: Robin Gloster <mail@glob.in>
stdenv: print message if structuredAttrs is enabled
stdenv: add _append
reduces the chance of a user doing it wrong
fix nix develop issue
output hooks don't work yet in nix develop though
making $outputs be the same on non-structuredAttrs and structuredAttrs
is too much trouble.
lets instead make a function that gets the output names
reading environment file '/nix/store/2x7m69a2sm2kh0r6v0q5s9z1dh41m4xf-xz-5.2.5-env-bin'
nix: src/nix/develop.cc:299: std::string Common::makeRcScript(nix::ref<nix::Store>, const BuildEnvironment&, const Path&): Assertion `outputs != buildEnvironment.vars.end()' failed.
use a function to get all output names instead of using $outputs
copy env functionality from https://github.com/NixOS/nixpkgs/pull/76732/commits
|
|
|
|
The LC_UUID is a hash over the output file contents.
|
|
POSIX sh (and `bash`) impose a restriction on environment variable name
format and disallow hypheps in the names. Normally it's not a problem
as nothing usually tries to refer nyphenated names.
One exception is `nix develop` (https://github.com/NixOS/nix/issues/6848):
$ nix develop -f. gcc -L
gcc-wrapper> ...-get-env.sh: line 70: expand-response-params: bad substitution
Note that bash usually uses explicitly created `expandResponseParams`
variant of the same variable.
To work the problem around let's avoid environment variable export and move
it to `passthru` for `cc` (used ina few places) and remove it completely for
`binutils` (does not seem to be used at all).
|
|
|
|
bintools-wrapper: Add dynamicLinker for uClibc
|
|
missed this in 1d44ac176ce6de74ac912a5b043e948a87a6d2f5
|
|
|
|
this shouldn't change any binary available in the default build environment
because bintools-unwrapped is already in path ( idk where it comes from but i know because objcopy is in path but not in the wrapper )
this just makes all the binaries available under 'bintools' instead of
having to use 'bintools-unwrapped'
reduces confusion because now 'objcopy' and others will be in 'bintools'
|
|
the same
when enableParallelBuildingByDefault is enabled
verified with
`nix-diff $(nix eval ".#gcc-unwrapped.drvPath") $(nix eval --expr 'with import ./. { config = { enableParallelBuildingByDefault = true; }; }; gcc-unwrapped.drvPath' --impure)`
|
|
|
|
|
