PE DLLs don't work like elf or mach-o, there's no way to define symbols
at run time, they must all be defined as import or export at link time.
As such there's no value in being able to have undefined symbols in
MSVC, nor does meson expose an option to change them
Fixes: #6342
If a user passes -fuse-ld=gold to gcc or clang, they expect that they'll
get ld.gold, not whatever the default is. Meson currently doesn't do
that, because it doesn't pass these arguments to the linker detection
logic. This patch fixes that. Another case that this is needed is with
clang's --target option
This is a bad solution, honestly, and it would be better to use $LD or a
cross/native file but this is needed for backwards compatability.
Fixes#6057
This partially reverts commit fe853ee516.
In particular this reverts the changes to the DynamicLinker __init__
methods. Frankly this is *bad* because it allows a mixin class (which
should not be directly instantiated) to be directly instantiated, and
complicates the init process. It also increases the amount of code for
zero gain, and makes the code less resilient to refactors.
This is returning the inverse of the correct value, which happens to
work out because in general the compilers that a link.exe-like linker is
paired with accepts the same arguments.
This dumps xild on mac and linux. After a lot of reading and banging my
head I've discovered we (meson) don't care about xild, xild is only
useful if your invoke ld directly (not through icc/icpc) and you want to
do ipo/lto/wpo. Instead just make icc report what it's actually doing,
invoking ld or ld64 (for linux and mac respectively) directly. This
allows us to get -fuse-ld working on linux.
The linker implementation split up introduced a regression: since the
AppleDynamicLinker subclass doesn't expose PIE support, builds using
that feature just plainly fail.
Add back support for it using the default and supported -pie flag.
It is perfectly valid to pass the arguments separately `-L /some/dir/`,
however, meson later groups arguments by whether they start with -L or
not, which breaks passing the -L and the directory separately.
Fixes#6003
Now that the linkers are split out of the compilers this enum is
only used to know what platform we're compiling for. Which is
what the MachineInfo class is for
Instead of the DynamicLinker returning a hardcoded value like
`-Wl,-foo`, it now is passed a value that could be '-Wl,', or could be
something '-Xlinker='
This makes a few things cleaner, and will make it possible to fix using
clang (not clang-cl) on windows, where it invokes either link.exe or
lld-link.exe instead of a gnu-ld compatible linker.
Before python 3.5.4 typing didn't have the NoReturn type, use a string
to forward declare it.
aside: I can't wait to be able to use python 3.7's
__future__.annotations and not have to deal wit hthis anymore.
Fixes#5822
This is a mixin class for DynamicLinkers that aims to provide only the
most basic posix-like linker arguments, in other words bits that gnu ld,
apple's ld, solaris's ld, and other completely disjoint linkers that are
used on Unix-like OSes share.
I started out just annotating, but realized there is a lot of really
silly duplication of methods in this module. Nearly all of the methods
return [], but each class implemented the same methods over and over!
I've fixed this by moving the default implementation down into the
`StaticLinker` class, and then overriding as necessary in the derived
classes.
It appears that LIB/LINK default to the host architecture if they can't
guess it from the first object. With the MSVC toolchain, resource files
are (usually) compiled to an arch-neutral .res format. Always
explicitly provide a '/MACHINE:' argument to avoid it guessing
incorrectly when cross-compiling.