It is possible to run a container or chroot with one ABI on a CPU and
kernel that would normally have a different ABI, most commonly by
running a 32-bit container on a 64-bit CPU and kernel. When we do a
native build in such an environment, the build and host architectures
are both equal to the architecture of the container, and it is safe to
assume that we can run executables from that architecture, because if
we could not, we wouldn't be running Python successfully.
Until now, we have been handling this by adding explicit special
cases in `machine_info_can_run()` for each known-good combination of
the detected CPU and the host architecture: every x86_64 can run x86
binaries, and every mips64 is assumed to be able to run 32-bit mips
binaries. However, the equivalent would not be true on ARM systems: *most*
aarch64 CPUs can run arm binaries, but not all (according to Wikipedia,
ARM Cortex-A34 is an example of a purely 64-bit CPU that cannot execute
32-bit instructions).
Instead, assume that if we are doing a native build (not a cross build),
by definition we can run build-architecture executables, and since the
host architecture is equal to the build architecture during a native
build, this implies that we can run host-architecture executables too.
This makes the behaviour of `need_exe_wrapper()` consistent with
`meson.can_run_host_binaries()`, which in turn avoids `Compiler.run()`
failing with error message "Can not run test applications
in this cross environment" during native builds even though
`meson.can_run_host_binaries()` has previously succeeded.
Resolves: https://github.com/mesonbuild/meson/issues/13841
Signed-off-by: Simon McVittie <smcv@debian.org>
Introduce a global Cargo interpreter state that keeps track of enabled
features on each crate.
Before generating AST of a Cargo subproject, it downloads every
sub-subproject and resolves the set of features enabled on each of them
recursively. When it later generates AST for one its dependencies, its
set of features and dependencies is already determined.
The clang-tidy-fix target uses run-clang-tidy to do the fixing, however
this script itself spawns `os.cpu_count()` threads as part of its
internal parallelism. When combined with Meson's parallelism this
results in the creation of potentially thousands of unecessary threads.
This commit rewrites the clang-tidy-fix to perform the same task
run-clang-tidy does but exclusively on Meson's thread pool. "Fix-it"
snippets are saved to `meson-private/clang-tidy-fix/` by a parallel
clang-tidy phase, afterwards (to avoid races) all collected fixes are
applied with a single call to clang-apply-replacements.
If need_exe_wrapper() is called while figuring out the language compiler,
the MachineInfo isn't complete yet, so machine_info_can_run() would return
False despite not cross compiling.
Make sure this fails loudly.
This reverts commit cc201a5396.
It's true that some aarch64 CPUs can run 32-bit ARM code, but some
(especially high-end ones, those most likely to be running builds)
cannot. It's better to assume that they can't, so builds don't
unnecessarily fail due to attempting to run a sanity check executable.
The documentation for subprocess.run at https://docs.python.org/3/library/subprocess.html#popen-constructor has a warning,
pointing to using shutil.which() instead of subprocess.run for detecting if exe files exists on the path.
shutil.which() is used in many places already.
As far as we can ascertain, the idea here was supposed to be that this version
at the bottom gets updated as a last-resort for development LLVMs on Debian.
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Places where compiler needs it already have access to Environment object
and can use it directly.
This fixes mypy complaining that not all compilers have self.exe_wrapper
in run() method that got moved to base class.
This replaces all of the Apache blurbs at the start of each file with an
`# SPDX-License-Identifier: Apache-2.0` string. It also fixes existing
uses to be consistent in capitalization, and to be placed above any
copyright notices.
This removes nearly 3000 lines of boilerplate from the project (only
python files), which no developer cares to look at.
SPDX is in common use, particularly in the Linux kernel, and is the
recommended format for Meson's own `project(license: )` field
lcov 2.0 deprecates `--rc lcov_branch_coverage=1` for `--rc branch_coverage=1` and
gives an error when an exclude is used on a non existing directory.
I added a version check for lcov and removed the subprojects directory from the
exclusion list if it does not exist.
Fixes#11995
The logic previously added to distinguish between illumos and Solaris made use of a uname invocation with a -o switch which is not supported on Solaris 5.10 or earlier.
illumos started with version 5.11 so the logic has been shortcut to report 'solaris' in such cases where the version is 5.10 or below.
If we have a build- or host-architecture compiler, we can detect mips64
vs. mips by the fact that mips64 compilers define __mips64. However,
machine_info_can_run() doesn't provide any compilers, because it is
interested in the architecture of the underlying kernel. If we don't
return mips64 when running on a mips64 kernel, machine_info_can_run()
will wrongly say that we can't run mips64 binaries.
If we're running a complete 32-bit mips user-space on a mips64 kernel,
it's OK to return mips64 in the absence of any compilers, as a result
of the previous commit "environment: Assume that mips64 can run 32-bit
mips binaries".
Resolves: https://github.com/mesonbuild/meson/issues/12017
Bug-Debian: https://bugs.debian.org/1041499
Fixes: 6def03c7 "detect_cpu: Fix mips32 detection on mips64"
Signed-off-by: Simon McVittie <smcv@debian.org>
The relationship between mips64 and mips is similar to the relationship
between x86_64 and x86. Representing it here is necessary so that we
will not require an exe_wrapper when cross-compiling for 32-bit mips on
mips64, or when a complete 32-bit mips user-space runs on a 64-bit kernel
without using linux32 to alter uname(2) to pretend to be 32-bit.
Signed-off-by: Simon McVittie <smcv@debian.org>
While both kernels are derived from the OpenSolaris project of Sun, they
have diverged and code that works with one may not work with the other.
As such, we should provide different values for them. This was requested
by both Oracle and the illumos upstreams.
Fixes: #11922
MIPS64 can run MIPS32 code natively, so there is a chance that a mixture
of MIPS64 kernel and MIPS32 userland exists. Before this Meson just
treats such mixture as mips64, because uname -m returns mips64.
So in this case we have to check compiler builtin defines for actual
architecture and CPU in use.
- Also fixes mips64 related detection tests in internaltests:
Normalize mips64 as mips first, then if __mips64 is defined, return
mips64 for mips64* machines.
This is a bit confiusing because normally one would detect if a flag
of 32-bit target is defined while running on a 64-bit machine. For
mips64 it is almost just the other way around - we need to detect if
__mips64 is set to make sure it is a mips64 environment.
Co-Authored-By: Jue Wang <maliya355@outlook.com>
This reverts commit 79d7891746.
This debug print probably should not have ended up live. Moreover, the
function it debugs is, surprisingly, called rather often. Adding I/O to
it causes it to begin to noticeably lag, on the scale of adding actual
*minutes* to a setup run.
Fixes#11322
There are lots of warnings that become fatal, that are simply unfixable
by the end user. Things like using old versions of software (because
they're using some kind of LTS release), warnings about compilers not
supporting certain kinds of checks, or standards being upgraded due to
skipped implementations (MSVC has c++98 and c++14, but not c++11). None
of these should be fatal, they're informative, and too important to
reduce to notices, but not important enough to stop meson if they're
printed.
It is only used by Environment.get_exe_wrapper() and every callers were
handling None already. Type annotation was wrong, it already could
return None for the case an exe wrapper is needed but none is provided.
Simon McVittie
Xavier Claessens
Xavier Claessens
Samuel Thibault
Jonathon Anderson
spaette
unknown
Jussi Pakkanen
Eli Schwartz
Jannik Glückert
Christoph Reiter
Alyssa Ross
Zhipeng Xue
Mads Andreasen
Sam James
dragonmux
Dylan Baker
Nigel Kukard
CorrodedCoder
L. E. Segovia
Eli Schwartz
Tristan Partin
Karol Herbst
Cyan
Josh Soref