Emitting -undefined,error was correct,, but starting with Xcode 15 / Sonoma,
doing so triggers "ld: warning: -undefined error is deprecated". Given that
"-undefined error" is documented to be the linker's default behaviour, this
warning seems ill advised. However, it does create a lot of noise. As
"-undefined error" is the default behaviour, the least bad way to deal with
this seems to be to just not emit anything. Of course that only works as long
as nothing else injects -undefined dynamic_lookup, or such. Complain to Apple.
Fixes: https://github.com/mesonbuild/meson/issues/12450
Previously macos reported "ld: unknown option: --version" when being passed
--version, but now sometimes it reports in plural, albeit without an obvious
pattern when. To handle that, simply just check for the prefix without the :
Fixes: https://github.com/mesonbuild/meson/issues/12552
The MSVC code is extremely confusing, and it turns out it actually
constructs debug (pdb) files names/path independently in separate
places. This is really hard to parse. Instead, refactor it so that the
source of the debug filename is within the target itself
(get_debug_filename). Add a couple of generic methods to retrieve the
full path of the debug filename name in the backend and use that when
needed.
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
Performed using https://github.com/ilevkivskyi/com2ann
This has no actual effect on the codebase as type checkers (still)
support both and negligible effect on runtime performance since
__future__ annotations ameliorates that. Technically, the bytecode would
be bigger for non function-local annotations, of which we have many
either way.
So if it doesn't really matter, why do a large-scale refactor? Simple:
because people keep wanting to, but it's getting nickle-and-dimed. If
we're going to do this we might as well do it consistently in one shot,
using tooling that guarantees repeatability and correctness.
Repeat with:
```
com2ann mesonbuild/
```
Since it's deprecated anyway, we don't really want to plumb it all the
way down into the build and backend layers. Instead, we can just turn
it into a `win_subsystem` value in the interpreter if `win_subsystem`
isn't already set.
A linker mixin has to be able to align with the base linker it will be
used for, in order to reference super(). Since they weren't inherited,
calls to super() resulted in mypy errors, which we ignored, and casting.
Use the same trick we use for compilers, and make the linker inherit
from the base linker type when running under mypy, and from object at
runtime.
* Archive shared library in AIX
This code change to ensure we archive shared libraries in AIX.
The things we do are:
Archive shared library
Install archived shared library
Build all must build the archived shared library
blibpath must have the archived shared library dependency.
* Archive shared library in AIX.
Made changes as per the review comments given in the first
PR request.
They are:-
Use self.environment.machines[t.for_machine].is_aix()
Remove trial spaces
Use of val instead of internal
Changed comments wherever requested
* Space after octothorpe
* Fixed failed test case causing build break during install section
* Moved AIX specific code to AIXDynamicLinker from backend
* Fix indentation, trailing spaces, add type annotations and Linux/macOS build break
* Remove some more trailing space issues
* Fixed the wrong return type in linkers
This saves on a 1500-line import at startup and may be skipped entirely
if no compiled languages are used. In exchange, we move the
implementation to a new file that is imported instead.
Followup to commit ab20eb5bbc.
Linkers that aren't actually ar, were refactored into a base class in
commit 253ff71e6b, which however didn't
take into account that we were doing checks for this.
The system linkers don't support this particular GNU extension on
these OS'es, so don't build them there.
Based on an OpenIndiana patch created by @alarcher. Closes#9882.
It turns out we don't generally need to proxy every compiler ever
through the top-level package. The number of times we directly poke at
one is negligible and direct imports are pretty clean.
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.
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.
mingw GCC using ld.bfd emits diagnostics that include
"-plugin-opt=-pass-through=-lmoldname" and this triggers a match for
mold when it should not.
Instead, always check the very beginning of the output for the linker
id. This is pretty consistent:
- it is always on stdout
- GCC may put additional things on stderr we don't care about
- swift is bizarre and on some OSes redirects the linker stdout to
swiftc's stderr, but it will still be the only stderr; we didn't even
check stderr at all until commit 712cbe0568
For gold/bfd linkers, the linker id is always the *second* word, after
the legally mandated "GNU" we already check for.
Previously, any value other than `windows` or `console` caused an
exception. This change allows for `efi_application` to be passed as
the `win_subsystem` to MinGW based linkers.
[why]
Support for the relatively new mold linker is missing. If someone wants
to use mold as linker `LDFLAGS="-B/path/to/mold"` has to be added instead
of the usual `CC_LD=mold meson ...` or `CXX_LD=mold meson ...`.
[how]
Allow `mold' as linker for clang and newer GCC versions (that versions
that have support).
The error message can be a bit off, because it is generic for all GNU
like compilers, but I guess that is ok. (i.e. 'mold' is not listed as
possible linker, even if it would be possible for the given compiler.)
[note]
GCC Version 12.0.1 is not sufficient to say `mold` is supported. The
expected release with support will be 12.1.0.
On the other hand people that use the un-released 12.0.1 will probably
have built it from trunk. Allowing 12.0.1 is helping bleeding edge
developers to use mold in Meson already now.
Fixes: #9072
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
These are only used for type checking, so don't bother importing them at
runtime.
Generally add future annotations at the same time, to make sure that
existing uses of these imports don't need to be quoted.
Using future annotations, type annotations become strings at runtime and
don't impact performance. This is not possible to do with T.cast though,
because it is a function argument instead of an annotation.
Quote the type argument everywhere in order to have the same effect as
future annotations. This also allows linters to better detect in some
cases that a given import is typing-only.
Andres Freund
Charles Brunet
Dudemanguy
Dylan Baker
Eli Schwartz
Tristan Partin
Jussi Pakkanen
Aditya Kamath
Karol Herbst
Nomura
Josh Soref
jack
Jan Janssen
Kleis Auke Wolthuizen
David Robillard
Alan Coopersmith
Tatsuyuki Ishi
Alf Henrik Sauge
Justin Blanchard
Lens
Fini Jastrow
William Toohey