| Age | Commit message (Collapse) | Author |
|---|
|
|
|
I failed to properly account for the case in which the two string are
completely equal.
(cherry picked from commit 4b31974ec5d73afd8deb5b89b35ad917ebef05ba)
|
|
Fedora, at the very least, now packages zlib-ng as zlib. This means the
version reported for the dependency is now X.Y.Z.zlib-ng by pkgconfig
whereas the test expected X.Y.Z. Make the version check work for both
regular zlib and zlib-ng.
(cherry picked from commit b1f4e1495d4f03f4ef68d59535bd954686def3af)
|
|
A GCC update broke this and is being investigated
Bug: #13465
(cherry picked from commit 0c93149f09bbeedd03c70abc7b6d652b8e9ee9fa)
|
|
Signed-off-by: Jannik Glückert <jannik.glueckert@gmail.com>
(cherry picked from commit 6258f0dc86188570e7d00316557bfb85948ed290)
|
|
We have permission to use that file. Fixes #13442.
(cherry picked from commit fa70974a647db90864df4af6172cf7766f79857b)
|
|
-m arguments aren't portable across architectures. -fipa-pta will
hopefully be portable for GCC, but also not implemented by clang.
Fixes: #13417
(cherry picked from commit 44323fffead913d0a3c52647ba63a236924c7b78)
|
|
by forcing an older nodejs
(cherry picked from commit 9cc94a16ab837e85c47a818668b98a110fbabc48)
|
|
URLError is a subclass of OSError and intermittent server errors can
manifest as OSError while reading instead of a URLError while
establishing a connection, which will cause the fallback url to be
ignored:
```
Looking for a fallback subproject for the dependency gudev-1.0
Downloading libgudev source from https://gitlab.gnome.org/GNOME/libgudev/-/archive/238/libgudev-238.tar.bz2
HTTP Error 404: Not Found
WARNING: failed to download with error: could not get https://gitlab.gnome.org/GNOME/libgudev/-/archive/238/libgudev-238.tar.bz2 is the internet available?. Trying after a delay...
HTTP Error 404: Not Found
WARNING: failed to download with error: could not get https://gitlab.gnome.org/GNOME/libgudev/-/archive/238/libgudev-238.tar.bz2 is the internet available?. Trying after a delay...
HTTP Error 404: Not Found
WARNING: failed to download with error: could not get https://gitlab.gnome.org/GNOME/libgudev/-/archive/238/libgudev-238.tar.bz2 is the internet available?. Trying after a delay...
WARNING: failed to download with error: The read operation timed out. Trying after a delay...
WARNING: failed to download with error: The read operation timed out. Trying after a delay...
ERROR: Unhandled python OSError. This is probably not a Meson bug, but an issue with your build environment.
```
(cherry picked from commit 8a202de6ec763284cbb7160b9d43d5e7e0703f19)
|
|
At an OS level, Unix-like OSes usually have very large or even
unlimited sized command line limits. In practice, however, many
applications do not handle this (intentionally or otherwise). Notably
Wine has the same limits Windows does, 32,768 characters. Because we
previously double counted most characters, we papered over most
situations that we would need an RSP file on Unix-like OSes with Wine.
To fix this issue I have set the command line limit to 32k, this is
still a massive command line to pass without an RSP file, and will only
cause the use of an RSP file where it is not strictly necessary in a
small number of cases, but will fix Wine applications. Projects who wish
to not use an RSP file can still set the MESON_RSP_THRESHOLD environment
variable to a very large number instead.
Fixes: #13414
Fixes: cf0fecfce ("backend/ninja: Fix bug in NinjaRule.length_estimate")
(cherry picked from commit a544c750b1d6d6d6cd3e617da6a060f3e5662a6a)
|
|
This causes us to not count the spaces between arguments, thereby
undercounting the number of elements. This is extra important because we
previously double counted all actual characters, covering this issue up.
Fixes: cf0fecfce ("backend/ninja: Fix bug in NinjaRule.length_estimate")
(cherry picked from commit 4842b8bcb37fe98f48b08e99210e04640380bffb)
|
|
(cherry picked from commit f76f9ddf28f16704b9d91066f6cc151fc78329e1)
|
|
Duplicated -delete_rpath arguments will cause macOS's install_name_tool
failed.
(cherry picked from commit 93f5ceb9eebfee229c15b31b935d8df6ad642a0b)
|
|
(cherry picked from commit a97de6b527c0109112909af8f29e8d262a87c247)
|
|
In commit c9aa4aff66ebbbcd3eed3da8fbc3af0e0a8b90a2 we added a refresh
call to git to catch cases where checking for uncommitted changes would
misfire. Unfortunately, that refresh performs a write operation, which
in turn misfires on readonly media. We don't actually care about the
return value of the refresh, since its purpose is solely to make the
next command more accurate -- so ignore it.
Fixes: c9aa4aff66ebbbcd3eed3da8fbc3af0e0a8b90a2
Fixes: #13461
(cherry picked from commit e9037e7b9ff81febbcef860dbfa785464ba3b457)
|
|
Fallout from the OptionStore refactor, and specifically commit
9a6fcd4d9a0c7bb248c5d0587632b741a3301e03. The `std` object was migrated
from having an option itself, to having the value fetched and saved
directly. In most cases, this also meant avoiding `.value`, but in a
couple cases this refactor went overlooked, and crashed at runtime.
Only affects Elbrus and Intel C++ compilers, seemingly.
Fixes #13401
(cherry picked from commit bc56a2c3469def7fafbdb38da6691cccb171e739)
|
|
Since they do not implement a default install dir like BuildTargets do.
gnome.compile_resources() would result in an unhandled python exception
when missing install_dir argument together with providing following arguments:
gresource_bundle: true
install: true
closes: https://github.com/mesonbuild/meson/issues/13447
Signed-off-by: RaviRahar <ravirahar33@gmail.com>
(cherry picked from commit 96f20d5b372b9982c153b114eb3726fbbecb7542)
|
|
aee941559 ("rust: recursively pull proc-macro dependencies as well")
had to be reverted (in a66cb97e8) because it broke Mesa cross
compilation. This happened because a C shared library was linked with
a Rust C-ABI static library, which caused it to inherit the proc macro
dependency the Rust static library was linked with.
The right way to handle this is for only Rust targets to inherit proc
macro dependencies from static libraries they link with. A Rust
executable, library, or whatever will need the proc macros its Rust
dependencies use, as illustrated in the test case that I've
reintroduced here.
I've verified that Mesa still cross compiles correctly with this
change. The same failure was also identified by the "rust/21
transitive dependencies" test case, but only when cross compiling, so
it wasn't caught by CI.
Co-authored-by: Xavier Claessens <xavier.claessens@collabora.com>
(cherry picked from commit a05f6a260ef4882f82da38ff1818ca8391b15bd8)
|
|
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.
(cherry picked from commit a51d5f36da85c1652c20254a522a9448147c4fbf)
|
|
In 8d7ffe6e863834f0190e need_exe_wrapper() use was copied which was just reverted,
so replace with is_cross there too, to keep things in sync.
(cherry picked from commit 76bd5548ae185e10a6cf3925980e8a18955e5c66)
|
|
c1076241af11f10acac28d771688bb54c6b0b340 changed the logic in multiple
places, in particular it looks like it was assumed that is_cross is always
the same as need_exe_wrapper(), but that's not true.
Also the commit only talks about mypy, so this was definitely not intended.
This reverts all the cases where need_exe_wrapper() was introduced back to
is_cross.
The change in backends.py could be a correct simplification, but I don't know
the code base enough, so reverting that too.
See #13403 and #13410
(cherry picked from commit d9e2dd6c806b5edf0f686c088fff2b3836ba1624)
|
|
This reverts commit cc201a539674babf46f726859587afb5ed6a6867.
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.
(cherry picked from commit 2fd7d64a50aa4f8a76d5b9ca13f7d8f8f40b959c)
|
|
Test dependencies can be of type CustomTargetIndex,
similar to other targets.
(cherry picked from commit f5d66b4932f94fbe78058e617c2d83a454107008)
|
|
|
|
Fixes building Nasm objects with Meson's native language support, when
depending against a library that exports that flag, like Glib.
|
|
|
|
Revert "interpreter: when overriding a dependency make its name match"
This reverts commit b1340e9bb1f243e4de8f2d89415a45ade476a3dc.
Revert "dependency: define equality and hash operators for Dependency"
This reverts commit 6d713e40f81512eadb0cc4654408d90cb22ba774.
This caused some projects to fail to build, such as libplacebo and
libepoxy. Taking libplacebo as the example, the produced build.ninja
does not include libvulkan.so as a linker input for
src/libplacebo.so.338.
We are probably getting dependency hashing wrong somewhere. Unsure where
exactly and unsure how to create a test case. We are also deep into rc2.
Revert it for now and try to re-land these changes for 1.6.
Bug: https://bugs.gentoo.org/935443
Fixes: #13352
|
|
Regression test for #13372
|
|
This reverts commit 9f02d0a3e5a5ffc82256391c244b1af38e41ef78.
It turns out that this does introduce a behavioral change in existing
users of ConfigurationData, which it wasn't supposed to (it was supposed
to preserve behavior there, and add a new *warning* for
EnvironmentVariables).
This breaks projects such as pulseaudio, libvirt, and probably more.
Roll back the change and try again after 1.5.0 is released.
Fixes: #13372
|
|
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.
|
|
When building a limited API module on Windows the library
to link with should be python3.dll, not python3X.dll. This was
already the case for non-GCC, but should have been the case
unconditionally.
|
|
They have recently upgraded to libgcrypt 1.11 and it has inherited the
gpg suite migration to pkg-config.
|
|
|
|
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.
|
|
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
|
|
Instead of making the variable optional, just return if we hit the error
case, since that's all that's going to happen anyway
|
|
Which requires injecting some extra paths and the `-Xpreprocess` flag,
as well as extra search paths for libomp and the headers.
Fixes: #7435
|
|
|
|
And into the Clang-CL mixin.
|
|
It was probably done this way originally since we didn't have the
`fatal` keyword argument to avoid triggering the fatal-meson-warnings.
While we're here, replace the use of a `if bool` with an `else` on the
for loop.
|
|
In case the OpenMP definition adds things like preprocessor directives
or include paths, like when building on MacOS with OpenMP from Homebrew.
|
|
This will be needed by the Apple compiler
|
|
format was adding a new empty line each time when trying to split a long line containing a function with no arguments
|
|
|
|
|
|
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.
|
|
|
|
|
|
_get_gnu_compiler_defines and _get_clang_compiler_defines were broken
by not defining the language they used.
Neither GCC nor Clang infer the language based on the driver name which means
`self.defines` isn't populated correctly in compilers/cpp.py.
e.g.
```
$ echo "" | g++ -E -dM - | grep -i cplus
$ echo "" | g++ -x c++ -E -dM - | grep -i cplus
#define __cplusplus 201703L
```
Fix that by passing '-cpp -x LANGUAGE' as a first pass. If it fails, try
again without '-cpp -x LANGUAGE' as before, as its portability isn't
certain. We do '-cpp' because during testing, I found Fortran needs this,
although per below, I had to drop Fortran in the end and leave it to the
fallback (existing) path.
Without this change, a63739d394dd77314270f5a46f79171a8c544e77 is only
partially effective. It works if the system has injected Clang options
via /etc/clang configuration files, but not by e.g. patching the driver
(or for GCC there too).
Unfortunately, we have to wimp out for Fortran and fallback to the
old method because you need the language standard (e.g. -x f95).
|
|
Make the debug & error message strings consistent between the GCC and Clang probes.
Copy-paste error. Here, we're scraping pre-processor tokens, not checking
for the compiler type.
|
