Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
This reverts commit 99ad11bd9c3249f548dda0b275d9f8dd1b3f6d14.
This breaks working setups in conda. It is either wrong or incomplete
and thus cannot be used.
Fixes #10737
|
|
e.g. ldc -- the compiler needs to process args before consuming them.
Fixes #10693
|
|
These make no sense as single strings.
|
|
What happens is this:
- liba is a convenience static library
- libb is an installed static library
- libb links in liba with --link-whole
- libc links to libb
- we generate a link line with libb *and* liba, even though libb is a
strict superset of liba
This is a bug that has existed since the we stopped using link-whole to
combine convenience libraries, and to instead propagate their
dependencies up. For most linkers this is harmless, if inefficient.
However, for apple's ld64 with the addition calling `ranlib -c`, this
ends up causing multiple copies of symbols to clash (I think that other
linkers recognize that these symbols are the same and combine them), and
linking to fail.
The fix is to stop adding libraries to a target's `link_whole_targets`
when we take its objects instead. This is an all around win since it
fixes this bug, shortens linker command lines, and avoids opening
archives that no new symbols will be found in anyway.
|
|
We need this to ensure that .mod files are created before we start
compiling, and to ensure that the proper include directory arguments are
generated.
|
|
|
|
There are two distinct cases here that need to be considered. The first
issue is https://github.com/mesonbuild/meson/issues/10723 and
https://github.com/mesonbuild/meson/issues/10724, which means that Meson
can't actually generate link-whole arguments with rust targets. The
second is that rlibs are never valid candidates for link-whole anyway.
The promotion happens to work because of another bug in the promotion
path (which is fixed in the next commit).
|
|
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
|
|
Fixes #10695
|
|
As per https://github.com/mesonbuild/meson/pull/10628#issuecomment-1230560772
the real fix will be in 0.64.
This reverts commits:
Revert "linkers: Add a representation for the Apple AR Linker"
ee16f01b6abc06c474ab8a91e19fa75e1253e132.
Revert "backends/ninja: run `ranlib -c $out` when using the apple ar"
77e589c4937cd77def8420f69756662d8b43cdba.
Revert "tests: Test extern'd globals on MacOS with the Apple Archiver"
bcb382b6403117513b0d7e77f01debb89fd54a45.
|
|
|
|
googletest 1.12.1 generates new JUnit4 invalid attributes file and
line.
Maybe all gtest "invalid" attributes are actually valid JUnit5
attributes, and maybe schema should be upgraded to JUni5.
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
|
|
Because clang now defaults to a dwarf version that valgrind does not yet
support. There's support in valgrind git master, though.
|
|
In order to reliably link to static libraries or individual object
files, we need to take their languages into account as well. For static
libraries this is easy: we just add the static library's list of
compilers to the build target. For extracted objects, we need to only
add the ones for the objects we use.
But we did this really inefficiently -- in fact, downright terribly. We
iterated over all source files from the extracted objects, then tried to
look up a new compiler for them. Even though the extracted objects
already had a list of compilers! This broke once compilers were made
per-subproject, because while the extracted objects have a reference to
all the compilers it needs (just like static archives do, actually) we
might not actually be able to look up that compiler from scratch inside
the current subproject.
Fix this by asking the extracted objects to categorize all its own
sources and return the compilers we want.
Fixes #10579
|
|
fixes #10566
|
|
This is needed for 6.1 support as noted in commit
a606ce22eb0dd05eef56384d59954edad7da131d but at the time there was no
pkg-config detection method at all. The stub code for Qt6 didn't support
libexecdir at all, and the pkg-config files added to newer versions of
Qt6 didn't export that information either until a further bugfix release.
Enforce that this information is required.
|
|
Add correct reading of pkgconfig-announced bindir and
pkgconfig-announced libexecdir. Will work only on 6.3+
|
|
If this command fails, for example when CXX is something not generic
enough to be a valid universal compiler command (clang -std=c++11
perhaps), we end up with two problems:
- it's impossible to figure out what Meson ran to get that error
- the error report isn't clear on what is stdout and what is stderr, or
even that that is what the message is about.
```
meson.build:1:0: ERROR: Unable to get clang pre-processor defines:
error: invalid argument '-std=c++11' not allowed with 'C'
```
What's C doing there and why is Meson talking about it? Answer: that's
compiler stdout. Say so.
|
|
We do something similar when running get_compiler() method checks from
the DSL. This ensures that if errors happen, the log file we tell people
to check actually works.
|
|
Use join_args to ensure that commands are rendered correctly.
|
|
Like when piped to something like less, where tqdm just makes a mess of
the output instead of providing something helpful.
|
|
Currently we invoke it with lang_args only, which is wrong and probably
useless.
Fixes misdetecting the linker when overridden as -fuse-ld, which led to
Meson trying to pass incompatible flags, outright failing if CFLAGS
contained flags that only work with a non-default linker, or in the most
benevolent case, having the status log report the wrong linker.
|
|
Use the same routines to handle output both when parsing the output and
when not. Also fixes broken stderr handling for parsed tests.
|
|
|
|
The Windows 2016 images have been deprecated for a while now and
regularly browning out. There's no viable replacement for testing that
we can generate a usable `--backend=vs2017` project, so we cannot
migrate this to anything else.
The deprecated images are finally fully removed. See
https://github.com/actions/virtual-environments/issues/5403
And now we get universal red CI, we cannot just wait for the brownout to
end to get a tiny little bit of final testing.
Simply remove the jobs so that we can tell if all the CI that actually
runs, is passing.
|
|
Environment line may not contain '=' and thus fail to decompose into a
key/value pair.
|
|
Although the former accepts multiple awaitables, it is only ever called
with a single one, so just use `wait_for` instead.
Additionally, the `try_wait_one` fails in Python 3.11, as
`Process.wait()` returns a coroutine, and `asyncio.wait` only accepts
tasks, so it errors out.
|
|
|
|
Not all "use -v" errors are Apple ld, and if it doesn't have better
output with -v instead of --version, we should not assume that is what
it is.
|
|
We do something similar when running get_compiler() method checks from
the DSL. This ensures that if errors happen, the log file we tell people
to check actually works.
|
|
Use join_args to ensure that commands are rendered correctly and with
less code.
|
|
follow standard variables and allow distributions to remove some entries from their cross-files
ex:
https://github.com/void-linux/void-packages/blob/f23acdd24bfade3a4e14809fafaffe09b3c3c318/common/build-style/meson.sh#L50-L54
variables chosen from the variables nixos sets
https://github.com/NixOS/nixpkgs/blob/ea0f14a502c60223c96066de3ed548cb3be8ca47/pkgs/build-support/bintools-wrapper/setup-hook.sh#L58
sorted alphabetically
|
|
|
|
(b, name) will always have the canonical tool name, not just a
potentially weird bin path. We need to check stderr for qt4 tools other
than lrelease, but we keyed off of the tool bin path, so matches were by
no means guaranteed, and specifically, would fail if the tool is looked
up via bindir.
This really should always have checked the canonical name, which is
guaranteed to be correct.
Partial fix for #10443
|
|
This forces the use of the Apple archiver, since that archiver doesn't
add extern'd variables to the symbol table automatically, and instead
requires that ranlib be used. A native file is used to ensure that
Apple's ar is used even in the presence of llvm or gcc in the path with
their superior archivers.
Co-authored-by: Dylan Baker <dylan@pnwbakers.com>
|
|
Apple's AR is old, and doesn't add externed symbols to the symbol table,
instead relying on the user calling ranlib with -c. We need to do that
for the user
|
|
Which is old and annoying and doesn't expose global symbols by default,
so we need a work around.
see: https://github.com/mesonbuild/meson/pull/10587
see: https://lists.gnu.org/archive/html/libtool/2002-07/msg00025.html
|
|
In commit 4ca9a16288f51cce99624a2ef595d879acdc02d8 we added unreliable
support (it warns you if you try it) for gcc-compatible treatment of
uppercase-C files being C++ instead of C. In order to handle it
correctly, we needed to evaluate can-compile by special-casing "C" to
avoid lowercasing it for comparisons.
This didn't cover all cases where we check if "C" is a C++ language
file. We also straight-up check the language of a file (rather than
working backwards to see if a C++ compiler can compile it) when doing
module scanning, and this needs to special-case "C" as well.
We also had one case where we only checked lowercase fortran extensions,
but not lowercase C++ extensions. While we are at it, use lowercase for
C++ as well, except the "C" special case.
Fixes #10629
|
|
work) based on host OS, not build OS.
|
|
|
|
When `self.wrap.filesdir` is a relative path, which happens when
`meson subprojects update` is run, the path to the patch must be
provided relative to the working directory in which `patch` or `git`
is run.
`self.wrap.filesdir` is absolute when `Resolve()` is invoked by the
Meson interpreter, which is why this wasn't detected by the tests.
|
|
In Fortran and C++ all the bits we care about are in ASCII. 8-bit
characters can only occur in comments and string literals and we don't
parse those.
|
|
Specifically, this is a combination of the following:
- Revert "visualstudio.py: Apply /utf-8 only on clang or VS2015+"
This reverts commit 6e7c3efa793c25259891d3b5471343f95fb061fa.
- Revert "Visual Studio: Only use /utf-8 on VS2015 or later or clang-cl"
This reverts commit 8ed151bbd786d2c52e6ea7b7cfe3147fc41ec041.
The changes were broken and untested, although this is because of a lack
of general CI testing for all languages on Windows. At least, this broke
the use of ifort, and possibly more.
The changes are fundamentally a bit "exciting", as they step out of the
hierarchy of compiler definitions and apply arguments almost willy-nilly.
And apparently it's leaky all over the place. I don't understand all of
what is going on with it, but it plainly failed to achieve its desired
goal and needs to be rolled back ASAP.
|
|
This enables the fortran tests for Azure.
We only test on x64, because:
- ifort isn't arm64 compatible
- x86 may in theory exist, but Meson reports it cannot compile
executables
|
|
These checked that e.g. the cpp and fc ids are identical, which isn't
strictly what we want. Particularly, msvc doesn't even have a fortran
compiler, and what we really care about is whether we mix both gcc and
something else.
|
|
This is only supported with gfortran, see "test cases/fortran/6 dynamic"
for more details. Skip it explicitly here too.
|
|
Fixes: #10570
|
|
|
|
according to commit https://github.com/wxFormBuilder/wxFormBuilder/commit/8a3d1697c819b8a8b41a136a865439b205997ae1
|