| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Fixes building Nasm objects with Meson's native language support, when
depending against a library that exports that flag, like Glib.
(cherry picked from commit 07777c725cf82a5ef4bb5c6d33fdcdbe3d688464)
|
|
Don't require the string to be enclosed in parentheses.
https://github.com/llvm/llvm-project/pull/97323 changed the LLD
version printout to no longer be enclosed in parentheses, which
made Meson fail to detect the linker style used here.
The LLD change is being reverted in
https://github.com/llvm/llvm-project/pull/97698 in order to fix
building with existing Meson versions, but for the future, loosen
the check slightly, to not require the parentheses.
(cherry picked from commit 1ca002a78a48faaf74aa61fcd28b4f2fa5937b47)
|
|
Fixes regression from commit 78e9009ff9d36925e04f329f9082841002ddd848.
The above commit relied on rpath_dirs_to_remove being present and
correctly filled, which was never the case for the AppleDynamicLinker.
The result was that all the build-dir-only RPATHs were being carried
over to the installed files.
This commit implements returning the list of RPATHs to remove in
AppleDynamicLinker, doing pretty much the same thing as what's in the
GnuLikeDynamicLinkerMixin. Thanks to that, depfixer now correctly
removes build-time Meson-created RPATHs, as it used to before 1.4.1.
(cherry picked from commit dc1b4be6be321e39d21604ab4287c9ce972be4da)
|
|
Fixes regression in commit 78e9009ff9d36925e04f329f9082841002ddd848.
new_rpath is only set when install_rpath appears in meson.build.
Before this commit, we treated new_rpath as a single string to pass to
-add_rpath. This worked as long as new_rpath had a single rpath in it,
though for ELF we explicitly supported multiple rpaths separated with
":" (as binutils ld is quite happy with that too).
install_name_tool does not support paths with colons in it:
```
21:12 <awilfox> Load command 19 cmd LC_RPATH cmdsize 40 path /bar:/baz:/eli:/ldap (offset 12)
21:12 <awilfox> Load command 20 cmd LC_RPATH cmdsize 24 path /foo (offset 12)
21:14 <awilfox> so the result is: do not use colons
```
After commit 78e9009ff9d36925e04f329f9082841002ddd848, we simply ended
up with one load command for LC_RPATH per char in new_rpath, which was
wrong in every possible case.
What we actually need to do is pass every distinct rpath as a separate
`-add_rpath` argument, so we split it on the colons instead. We do the
same splitting to ensure proper diff'ability for ELF anyways...
Fixes #13355
(cherry picked from commit 7b43a2e19613f3702935872b21b1020f7d8c6a9b)
|
|
In commit 2cb7350d1679fb61826bf4aebfb0f75a9b9103e3 we added a special
case for environment() objects to allow skipping `meson --internal exe`
overhead when /usr/bin/env exists and can be used to set environment
variables instead of using a pickled wrapper.
This special case assumed that environment is used for setting
variables, but it is also possible, albeit less common, to
append/prepend to them, in which case `meson --internal exe` will
compute the final value as an offset from whatever the current environment
variables inherited from ninja are. It is not possible to precompute
this when generating command lines for ninja, so using arguments to
/usr/bin/env is not possible. All it can do is set (override) an
environment variable.
In this case, we have to use the python wrapper and cannot optimize it
away. Add a tracking bit to the env object and propagate it to the
backend.
(cherry picked from commit aab2533ab4f7f4c16991620b400d71782f89be1c)
|
|
(cherry picked from commit 1570289acf28272aa6f1e029a32229ad6f276d94)
|
|
There are two issues:
1. has_header() wants just the header name without surrounding <>
or similar; it fails otherwise.
2. has_header() returns a tuple of two bools, where the first element
determines whether or not the header has been found. So use
that element specifically, otherwise the tuple will always evaluate
to true because it is not empty.
Fixes: 675b47b0692131 ("compilers: cpp: improve libc++ vs libstdc++ detection (again)")
(cherry picked from commit eba5498e9b40fdc6fd7d9621a9262dbd8364ea62)
|
|
Found by Coverity scan.
(cherry picked from commit a6258eb5e2660598b1039cf6ee88692a9091affd)
|
|
This fixes the unit test `TestAllPlatformTests.test_noop_changes_cause_no_rebuilds`,
when run with an `nm` binary from `cctools-port` (as shipped by conda-forge, see
https://github.com/conda-forge/cctools-and-ld64-feedstock).
It also addresses the issue discussed in https://github.com/mesonbuild/meson/discussions/11131,
and this build warning:
```
[48/1383] Generating symbol file scipy/special/libsf_error_state.dylib.p/libsf_error_state.dylib.symbols
WARNING: ['arm64-apple-darwin20.0.0-nm'] does not work. Relinking will always happen on source changes.
error: arm64-apple-darwin20.0.0-nm: invalid argument --
```
as reported in scipy#20740.
The unit test traceback was:
```
> self.assertBuildRelinkedOnlyTarget('mylib')
E AssertionError: Lists differ: ['mylib', 'prog'] != ['mylib']
E
E First list contains 1 additional elements.
E First extra element 1:
E 'prog'
E
E - ['mylib', 'prog']
E + ['mylib']
unittests/allplatformstests.py:1292: AssertionError
```
The `nm` shipped by Apple yields the exact same results either way; the man page for `nm`
only lists the single-character form so this seems preferred either way.
(cherry picked from commit bcbf0685492c61fbc9acac3e7b808a5036dd2439)
|
|
Closes gh-13319
(cherry picked from commit 2058f63b4e2d67cbe835499a43d8415f3c1d940d)
|
|
Arch profile.d scripts were converted to use an appending function that
disappears when /etc/profile exits, and overall are simply not suitable
-- any more -- for sourcing individually.
(I will freely admit I'm not really sure what the overall goal of
refraining from sourcing /etc/profile itself is. Arguably it's kind of
misuse of the profile...)
This silently broke the cuda tests, which never ran because the cuda
compiler was not detected as available.
While we are at it, I guess we can convert gentoo to use the same trick
of appending it in install.sh
(cherry picked from commit d9e3a3f09ff82fafab85f1d8631c9e8689850510)
|
|
Fixes #13269
(cherry picked from commit f4577911b4c608f11e01e6fca26c1c78f46e5797)
|
|
|
|
(cherry picked from commit 6f3841e98636b8460b8dc4e57a14a36fb7ddb815)
|
|
`add_languages('cuda')` later
(cherry picked from commit 7f2c6f644b83f27d1f46aacf8ac59722498529ff)
|
|
They were skipped with llvm 17 based on the version, and they are
now no longer skipped with v18 and also pass now.
This depends on #12964 for llvm 18 support in meson.
(cherry picked from commit 80e1d28b042def24b7325f84247dadf94c507bfd)
|
|
|
|
It started failing CI as soon as the default shifted to 1.78. Something
is broken and it prevents running stable CI. Tracking issue opened.
|
|
A bare return at the end of a function doesn't do anything. And in the
case of a try/except, it's really just an elaborate "pass" anyway.
(cherry picked from commit aa9b7b9445ad5bf0948cadac86109ba40e193424)
|
|
conditional
We do:
```
if is_thing:
assignme = value
if_is_thing:
...
else:
assignme = []
```
It is always defined on both sides, but there was no particular reason
we had to assign it in the later copy. pylint reported it as a false
positive, and it may prove confusing in general, and it's harmless to
move, so do so.
(cherry picked from commit 125d3344ec3361b2fb6d35c6c75c3f6d4f500556)
|
|
It does no control flow analysis, and upgrading to pylint 3.2.0 produced
many incorrect warnings.
Also ignore contextmanager-generator-missing-cleanup for now. It has FP
when there is no code after a yield (and thus no cleanup needs to be
handled), which is what we do. Currently under discussion upstream:
https://github.com/pylint-dev/pylint/issues/9625
(cherry picked from commit e343590e7d59b4bfd6bc4913ac20ac9c46e702a4)
|
|
We cover every case as if/elif/elif. mypy can handle this fine, but
pylint doesn't do control flow or type checking and thinks in the
missing else case, the variable might not be defined.
For mypy as well, doing this instance check is unnecessary as it can be
inferred. So just micro-optimize the check and allow pylint to safely
analyze the logic.
(cherry picked from commit 29a62ff794df3d72616740be9723b87f6b491722)
|
|
On Apple Silicon the default search path is /opt/homebrew instead of
/usr/local.
(cherry picked from commit 80b9b125f47ff2cffa9f603fb86e6e237a039881)
|
|
Boost now requires C++ 14, as of 1.82
(cherry picked from commit ff95c7d08393a24d60a8b53bb1c2bee76300e822)
|
|
(cherry picked from commit b732070a642e7cdbf95886ef23a4e5b8d4737042)
|
|
There are some additional packages that seem to be needed on Apple based
Silicon.
(cherry picked from commit d40e679c4798b4d3ae90e09ee376ddc0df0a0054)
|
|
homebrew installs to /usr/local on Intel based macs, but has moved to
/opt/homebrew for those using Apple Silicon.
(cherry picked from commit 274445d247afd44afc408af5a8d130ae9a7c270c)
|
|
Qt4 doesn't seem to work on Apple Silicon because OpenSSL 1.0 (a
requirement for Qt4) doesn't build on it correctly, trying to use X86
assembly.
(cherry picked from commit 869bb7bc423db0bd176eab6d0c8662bfe7be74bf)
|
|
We have two copies of other.h, one of which is generated. If we don't
include the include/ directory then building fails unless the
custom_target which copies it over, happens to run early enough. On
parallel builds this may fall on its face.
(cherry picked from commit 1baabbc7f6729d2a94feb277054184233eae87d7)
|
|
Any code that needs to know mesonlib.python_command currently assumes
the PyInstaller bundle reference is added to the sys module, which means
that it assumes the only freeze tool used is PyInstaller. Really, all we
need to check is sys.frozen as it's never normally set, but always set
for a freeze. We don't care if it was PyInstaller specifically, and we
don't need its bundle directory.
See https://github.com/mesonbuild/meson/discussions/13007
(cherry picked from commit f9eef40982ba2715aa4ca1d925aca423646c48f3)
|
|
Popen_safe_logged has a small inefficiency. It evaluates the stripped
version of stdout/stderr before checking if it exists, for logging
purposes. This would sometimes crash, if it was None instead of ''.
Fixes #12979
(cherry picked from commit c99fc40bb7bacfed4ea79b4b83bec46fdc5018f3)
|
|
(cherry picked from commit 4b5caa887851613878be29410decb45477f0a3bc)
|
|
It's utterly broken, and only works when one path is inside the other:
Traceback (most recent call last):
File "/usr/lib/python3.12/site-packages/mesonbuild/mesonmain.py", line 194, in run
return options.run_func(options)
^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/site-packages/mesonbuild/mdevenv.py", line 188, in run
write_gdb_script(privatedir, install_data, workdir)
File "/usr/lib/python3.12/site-packages/mesonbuild/mdevenv.py", line 142, in write_gdb_script
rel_path = gdbinit_path.relative_to(workdir_path)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.12/pathlib.py", line 682, in relative_to
raise ValueError(f"{str(self)!r} is not in the subpath of {str(other)!r}")
ValueError: '/path/to/builddir/.gdbinit' is not in the subpath of '/path/to/workdir'
ERROR: Unhandled python exception
This is a Meson bug and should be reported!
(cherry picked from commit 069d89223769a380ccecd069a01e3bd5d71fdef3)
|
|
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>
(cherry picked from commit 2ac5c4b72081735cc9a2b67e5671c1afe682fcae)
|
|
In 67afddbf431140c1ee064bf79a2fa5a95575488e, we added LLVM 18, but LLVM >= 18
uses a new version scheme of X.Y, not X.0.Y (where using "X" was enough).
See https://discourse.llvm.org/t/rfc-name-the-first-release-from-a-branch-n-1-0-instead-of-n-0-0/75384.
Without this, I get a test failure:
```
mesonbuild.interpreterbase.exceptions.InterpreterException: Assert failed: config-tool and cmake returns different major versions
-> frameworks: 15 llvm (method=combination link-static=False)
```
Fixes: https://github.com/mesonbuild/meson/issues/12961
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
(cherry picked from commit dec93ce9a52b234ed4cb25646eaf13c503ba739a)
|
|
On Arch's shiny new 48-core/96-thread build server, the
`test_install_log_content` test fails because of an unexpected
`invalid-symlink.txt` file. Apparently the test runs in parallel with
`test_install_subdir_symlinks`, which modifies the `59 install subdir`
source directory.
To fix this, make `install_subdir_invalid_symlinks` copy the entire test
into a tmpdir before modifying it.
(cherry picked from commit 05bbe45cc228c78c47f57c88a04acd937a60f8bb)
|
|
This is a useful thing to do when a test needs to modify the source
tree, as it prevents races between tests.
(cherry picked from commit 6db1d2bca5eaf9ff3f92249340da7b66c91d26c5)
|
|
This reverts commit aee941559c4b88a062e88186819a820c69c200ae.
The commit being reverted breaks compilation of a major Meson consumer
(Mesa). As a result, various distros are either pinning to <1.4.0 (before
the commit) or performing this same revert downstream.
Fixing a regression takes priority, so let's revert.
Fixes: https://github.com/mesonbuild/meson/issues/12973
(cherry picked from commit a66cb97e8cd29e6d8c89232b8e3763677ad3825f)
|
|
(cherry picked from commit 7efddcb90951cdbd177024721bafabd38c8d0dad)
|
|
* Previously, cuda would just plainly prepend `-l` to the libname.
* By relying on the host compiler to find libraries, we now get
more subtle failures, such as CUDA modules not being found
anymore.
* We need to simplify these CUDA modules when nvcc is used for
linking, since this may have side-effects from the cuda toolchain.
Closes: #13240
(cherry picked from commit 4861079360423298b7c282becab46bdcdee8f8f6)
|
|
Emscripten version numbers are unrelated to Clang version numbers,
so it is necessary to change the version checks for `c_std=c17` & co.
Without that, no project that defaults to C17 or newer will build with
Emscripten.
See https://github.com/pyodide/pyodide/discussions/4762 for more
context. Also note that this bug caused defaulting to C17 in
scikit-learn to be reverted (scikit-learn#29015), and it may be a
problem for SciPy 1.14.0 too since that release will upgrade from C99
to C17.
Co-authored-by: Loic Esteve <loic.esteve@ymail.com>
(cherry picked from commit 77db04ffa6c37496f5a800f2f5cd5a0c19e47d8b)
|
|
(cherry picked from commit 14de8ac5a9e04490a67e3ddcbd44b31915aed1b9)
|
|
Bug: mesonbuild/meson/pull/9453
Bug: mesonbuild/meson/issues/9479#issuecomment-953485040
(cherry picked from commit b6e5683764c5b296a98b67c0a2ec11fbd9f59c71)
|
|
(cherry picked from commit 89a5bde9d98ecc96bb462872bb2d83ac762ffc08)
|
|
(cherry picked from commit c55ca8272c536d439253d38600f3c9e445b1edf7)
|
|
* In `CudaDependency._detect_language`, the first detected language is
considered the linking one. Since `nvcc`/`cuda` implicitly know where the
cuda dependency lives, this leads to situations where `cpp` as linking
language is erroneously detected as `cuda` and then misses the `-L` argument.
(cherry picked from commit 33adc420f318acfa80b6d6bceb79084eded0d3a0)
|
|
We need the subdir of where the output file will actually be created,
not the current subdir of the interpreter.
Fixes: #13168
(cherry picked from commit 23eb7ba700cd6c53d5491cc4f99c532629efa1e2)
|
|
(cherry picked from commit f1f24816a912bacbb32931bfbd034be36138e3e4)
|
|
(cherry picked from commit e3db7af0ea41ea120f9d2dfedba309522575c5e7)
|
