Running some container-like mechanisms such as chroot(1) from sudo, can
result in a new isolated environment where the environment variables
exist but no users exist. From there, a build is performed as root but
installation fails when we try to look up the passwd database entry for
the user outside of the chroot.
Proper container mechanisms such as systemd-nspawn, and even improper
ones like docker, sanitize this and ensure those stale environment
variables don't exist anymore. But chroot is very low-level.
Avoid crashing when this happens.
Fixes#11662
A user might run `sudo somewrapper` to build and install something with
meson, and it is not actually possible to drop privileges and build,
since the build directory is also owned by root.
A common case of this is `sudo pip install` for projects using
meson-python or other python build-backends that wrap around meson.
Fixes#11665
The paths in meson.build use / as path separator, however, the paths
constructed during the directory structure walk use native path
separators, thus the path never compare equal to the excluded ones.
Normalize the exclusion paths before the comparison.
We need to remember its value when reconfiguring, but the Build object
is not reused, only coredata is.
This also makes CLI more consistent by allowing `-Dvsenv=true` syntax.
Fixes: #11309
It can only be used for projects that don't have any rules at all, i.e.
they are purely using Meson to:
- configure files
- run (script?) tests
- install files that exist by the end of the setup stage
This can be useful e.g. for Meson itself, a pure python project.
It's actually Generic, and we should use Generic annotations to get the
correct result. This means that we don't have to assert or cast the
return type, because mypy just knowns
Do not allow hanging forever.
It's fine to use selectors here, which are unix-only, because we require
Unix + a system that has e.g. sudo installed, anyway.
If the user runs `sudo meson install` this may run ninja to build
everything that gets installed. This naturally happens as root also, by
default, which is bad. Instead, detect root elevation tools and drop the
uid/gid of the child ninja process back to the original invoking user
before doing anything.
There's a couple issues with the current approach:
- pkexec is an unusual elevation method, the standard is sudo
- it tries to elevate even in automated workflows
- the user may not want to automatically rerun as root, that might be
badly behaved
Do some upfront checks instead, first to make sure it even makes sense
to try becoming root, and then to ask the user "do you really want
this". Also check for a couple common approaches to root elevation,
including doas.
Fixes#7345Fixes#7809
We just finished running rebuild_all, and then actually running
the install routine failed because of permission errors, so we magically
reran as root. But we should *know* that all prerequisite targets are up
to date already, we don't need to run it *again*.
Nevertheless, when running meson install directly we could end up
without --no-rebuild in the original argv. This meant that it wouldn't
be in the re-executed argv either. Add it on just in case -- repeating
it twice doesn't hurt anyway.
install_mode can include the setuid bit, which has the special property
(mentioned in the set_mode logic for minstall itself) of needing to come
last, because it "will get wiped by chmod" (or at least chown).
In fact, it's not just chown that wipes setuid, but other changes as
well, such as the file contents. This is not an issue for install_data /
custom_target, but for compiled outputs, we run depfixer to handle
rpaths. This may or may not cause edits to the binary, depending on
whether we have a build rpath to wipe, or an install rpath to add. (We
also may run `strip`, but that external program already has its own mode
restoration logic.)
Fix this by switching the order of operations around, so that setting
the permissions happens last.
Fixes https://github.com/void-linux/void-packages/issues/38682
When need to catch exceptions just like we do in coredata.load() to
print proper error message instead of backtrace when user mix meson
versions.
This happens frequently when user has a newer version of meson installed
in their HOME and then "sudo meson install" uses the system version of
meson.
In case a link is pointing_to an absolute path and we are using $DESTDIR
we fail in case the target is missing.
This is incorrect because we may need to use an absolute path to an
already installed file that is in $DESTDIR.
So if an absolute target is not existing, check if we have such file in
$DESTDIR before failing for real.
RuntimeError is way too generic when we have an explicit class for
"Meson reports to the user, something went wrong".
Moreover we now tell people that generic exceptions are "Meson bugs and
should be reported", so our failure to do the technically correct thing
and report the right kind of exception means we get haunted by demons of
confusion. Specifically, people complain to us that Meson told them
"there is a bug in Meson" when their install fails due to meson.build or
build environment issues.
This was a nice idea in theory, but in practice it had various problems:
- On the only platform where ldconfig is expected to be run, it is
really slow, even when the user uses a non-default prefix and ldconfig
doesn't even have permission to run, nor can do anything useful due to
ld.so.conf state
- On FreeBSD, it bricked the system: #9592
- On cross builds, it should not be used and broke installing, because
ldconfig may not be runnable without binfmt + qemu: #9707
- it prints weird and confusing errors in the common "custom prefix"
layout: #9241
Some of these problems can be or have been fixed. But it's a constant
source of footguns and complaints and for something that was originally
supposed to be just "it's the right thing to do anyway, so just do it
automatically" it is entirely too risky.
Ultimately I do not think there is justification for keeping this
feature in since it doesn't actually make everyone happy. Better for
users to decide whether they need this themselves.
This is anyways the case for cmake and autotools and generally any other
build system, so it should not be too intimidating...
Fixes#9721
Otherwise we might not find a ninja that was picked up from the Visual
Studio installation.
```
$ meson setup _build
...
Activating VS 15.9.40
...
Found ninja-1.8.2 at "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\Ninja\ninja.EXE"
$ meson compile -C _build
Activating VS 15.9.40
...
$ meson install -C _build
Can't find ninja, can't rebuild test.
```
Fixes https://github.com/mesonbuild/meson/issues/9774
For libraries installed to libdir, it's not expected to have rpath
hooked up. But for non-default libdirs, the path might not get searched
by default. `ldconfig -m <libdir>` is convenient here, as it will
programmatically add a new directory to search for shared libraries, so
the resulting installed programs work out of the box.
Include the dragonfly BSD platform name, which doesn't match the 'bsd'
catch-all pattern.
They don't utilize a soname cache, so running ldconfig without arguments
is basically pointless -- and at least some of them are buggy: running
ldconfig with the verbose flag switches on "delete all directories from
the hints file, and recreate it using 0 command-line positional
arguments", which would soft-brick the system.
Fixes#9592
This replaces the absolute hack of using
```
install_subdir('nonexisting', install_dir: 'share')
```
which requires you to make sure you don't accidentally or deliberately
have a completely different directory with the same name in your source
tree that is full of files you don't want installed. It also avoids
splitting the name in two and listing them in the wrong order.
You can also set the install mode of each directory component by listing
them one at a time in order, and in fact create nested structures at
all.
Fixes#1604
Properly fixes#2904
On linux system ldconfig needs to be called to update
the ld.so.cache to be able to load libraries from
/usr/local/lib/x86_64-linux-gnu on debian based
distributions for example.
Meson already works like that, except in do_copydir() that requires
absolute destdir. Better explicitly support that instead of leaving it
undefined and unconsistent.
"meson setup" is resolving symlinks for the build directory in
validate_core_dirs. For consistency with it, do the same when
the build directory is passed via -C to devenv, dist, init, install
and test.
This ensures for example that the path to test dependencies is
computed correctly in "meson test".
Fixes: #8765
The existing code works, but it probably doesn't do what the author
thought it would do. `(x or y or z) is not None` works by checking that
each of those things are *truthy* in turn, and returning the first
truthy value, which is compared against None. Using `all()` makes it
very clear that what you want to do is make sure that each value is not
None.
If a custom_target output is a directory, we install it as a directory,
not as a file. And, we try to track subdirectories which are created so
uninstalling works. But one directory creation did not go through
DirMaker, in the case where the output directory does not have any
further subdirectories.
Consolidate on makedirs, since I don't see much point in using os.mkdir
right here.
In commit caab4d3d, the uid and gid arguments passed to os.chown() by
set_chown() were accidentally swapped, causing files to end up with
incorrect owner/group if the owner and group are not the same.
Also update the documentation to better indicate which argument to
install_mode is which.
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Eli Schwartz
Daniele Nicolodi
Josh Soref
Xavier Claessens
Dylan Baker
Charles Brunet
L. E. Segovia
Rosen Penev
Marco Trevisan (Treviño)
Nirbheek Chauhan
Pablo Correa Gómez
Christian Clauss
Stéphane Cerveau
Paolo Bonzini
Daniel Mensinger
Peter Kjellerstedt