Having multiple compilers in the build environment would result in an
invalid LD_DYLD_PATH like /usr/lib/dyld/usr/lib/dyld.
Since the path is hardcoded in XNU it can't be anything but
/usr/lib/dyld anyway.
This fixes a bug introduced in #27831: `for path in "$dir"/lib*.so` assumed that
all libs match `lib*.so`, but 07674788d6 started
adding libs that match `*.so` and `*.so.*`.
`makeWrapper` and `wrapProgram` are being invoked on all kinds of
wacky things (usually with the help of bash globs or other machine
assistance).
So far, I have come across `wrapProgram` being invoked on a directory,
as well as on the empty string.
As far as I can tell, it's only valid to invoke these utilities on a
normal (non-directory, non-device) executable file. This commit
enforces that precondition.
Previously, makeWrapper would accept arguments it didn't recognize,
potentially allowing argument misspellings or broken callers.
Now, makeWrapper dies with a backtrace if it is called incorrectly.
Also changes `wrapProgram` so that it doesn't pass through the first
argument twice --- this was tripping up the argument checking.
Now is an opportune time to do this, as the infixSalt conversion in
`add-flags.sh` ensures that all the relevant `NIX_*` vars will be
defined even if empty.
This is basically a sed job, in preparation of the next commit. The
rules are more or less:
- s"NIX_(.._WRAPPER_)?([a-zA-Z0-9@]*)"NIX_\1@infixSalt@_\2"g
- except for non-cc-wrapper-specific vars like `NIX_DEBUG`
This is an ugly temp hack for cross compilation, but now we have something better on the way.
Bind `infixSalt` as an environment variable as it will be used in it.
Some programs store the executable in a different place and link it
from the `bin` directory. For example, Polari links `$out/bin/polari`
to `$out/share/polari/org.gnome.Polari`. `wrapGAppsHook` did not follow
symlinks so it was not able to wrap Polari, making it unable to access
GObject introspection definitions required for running the program.
I made the wrapping script follow symlinks to fix this corner case.
In 8d76eff, @Ericson2314 changed the representation of the value that
`findInputs` generated from a whitespace-separated bunch strings to an
actual array of strings.
Expressions that *consume* that value, however, also needed to be
changed to iterate over all the contents of the array, else they would
only select the first value, which turns out to be somewhat limiting.
Fixes#27873
The image json is not exactly the same as the layer json, therefore I
changed the implementation to use the `baseJson` which doesn’t include
layer specific details like `id`, `size` or the checksum of the layer.
Also the `history` entry was missing in the image json. I’m not totally
sure if this field is required, but a I got an error from a docker
registry when I’ve tried to receive the distribution manifest of an
image without those `history` entry:
GET: `http://<registry-host>/v2/<imageName>/manifests/<imageTag>`
```json
{
"errors": [
{
"code": "MANIFEST_INVALID",
"message": "manifest invalid",
"detail": {}
}
]
}
```
I’ve also used a while loop to iterate over all layers which should make
sure that the order of the layers is correct. Previously `find` was
used and I’m not sure if the order was always correct.
callPackage already calls makeOverridable, but that just
makes the function that evaluates to buildEnv overridable,
not buildEnv itself.
If no overridable version of buildEnv is used during construction,
users can't override e.g. `paths` at all
Unified processing of command line arguments in ld-wrapper broke support for
`NIX_DONT_SET_RPATH` and revealed that ld-wrapper adds the directory of its
`-plugin` argument to runpath. This pull request fixes that. It treats
`dir/libname.so` as `-L dir -l name`, because this is how `ld.so` interprets
resulting binary: with `dir` in `RUNPATH` and the bare `libname.so` (without
`dir`) in `NEEDED`, it looks for `libname.so` in each `RUNPATH` and chooses the
first, even when the linker was invoked with an absolute path to `.so`.
As described in https://github.com/NixOS/nixpkgs/issues/18461, MacOS no
longer accepts dylibs which only reexport other dylibs, because their
symbol tables are empty. To get around this, we define an object file
with a single "private extern" symbol, which hopefully won't clobber
anything.
If the base image has been built with nixpkgs.dockerTools, the image
configuration and manifest are readonly so we first need to change
their permissions before removing them.
Fix#27632.
The time to expand rpath was proportional to the number of -L flags times the
number of -l flags. Now it is proportional to their sum (assuming constant
number of files in each directory in an -L flag).
Issue reported by @nh2 at https://github.com/NixOS/nixpkgs/issues/27609#issuecomment-317916623
This setup hook is propagated by gdb. Thus, a typical use is:
$ nix-shell -p gdb nix nix.debug sqlite.debug ...
and gdb will be able find the debug symbols of nix etc. automatically.
The docker loading (docker 1.12.6) of an image with uppercase in the
name fails with the following message:
invalid reference format: repository name must be lowercase
As @oxij points out in [1], this breakage is especially serious because
it changes the contents of built environments without a corresonding
change in their hashes. Also, the revert is easier than I thought.
This reverts commit 3cb745d5a6.
[1]: https://github.com/NixOS/nixpkgs/pull/27427#issuecomment-317293040
Fixes#27406.
Commit 5d4efb2c81 added an assertion to `stopNest'
which requires it be correctly paired with `startNest'. `fetchurl' calls
`stopNest', but never calls `startNest'; the former calls are removed.
The `DISPLAY` environment variable is propagated into chroots built with
`buildFHSUserEnv`, but currently the `XAUTHORITY` variable is not. When
the latter is set, its value is usually necessary in order to connect to
the X server identified by the former.
This matters for users running gdm3, for example, who have `XAUTHORITY`
set to something like `/run/user/1000/gdm/Xauthority` instead of the X
default of `~/.Xauthority`, which doesn't exist in that setup.
Fixes#21532.
Since 3cb745d5a6, the format of
propagated-user-env-packages has changed and propagated packages have not been
included by buildenv, including in the system environment.
The buildenv builder is modified to read propagated-user-env-packages
line-by-line, instead of expecting all packages on one line.
Besides deduplicating overlapping logic, clear warning messages were
added for:
- No glob/path for dynamic linker provided (use default glob)
- Glob did not expand to anything (don't append flag)
- glob expanded to multiple things (take first, like before)
This makes those files a bit easier to read. Also, for what it's worth,
it brings us one baby step closer to handling spaces in store paths.
Also, I optimized handling of many transitive deps with read. Probably,
not very beneficial, but nice to enforce the pkg-per-line structure.
Doing so let me find much dubious code and fix it.
Two misc notes:
- `propagated-user-env-packages` also needed to be adjusted as
sometimes it is copied to/from the propagated input files.
- `local fd` should ensure that file descriptors aren't clobbered
during recursion.
They're additional commits from #26877.
Changing names of the fetched stuff was changing very many hashes,
and I think it's better to avoid that for the moment to reduce work
needed by nixpkgs users. The fetchers are expected to be commonly
used even outside nixpkgs, and the current naming wasn't that bad
usually.
(commit analogical to d10c3cc5eedf58e80e2; I haven't noticed the part of
the PR has already got to master)
The freedesktop specification says that the autostart folder is located at $XDG_CONFIG_DIRS/autostart.
Nixos defines XDG_CONFIG_DIRS as /etc/xdg. So we need to copy the desktop files into the right folder
with make-startupitem.
