In get_library_dirs() we are trusting the compiler to return a correct
list of directories to search for libraries, based on whether or not
we are compiling 64-bit or 32-bit. Unfortunately, this is often not the
case, as 64-bit libraries often are returned when compiling with -m32 on
a 64-bit OS.
Since system directories do not contain a mix of libraries, the solution
here is to check each directory, by picking a .so file in the directory
and checking whether its 64-bit or 32-bit. If we can't determine if we
want 32-bit or 64-bit, just skip the checks and assume the directory is
good.
Autotools will add endianess to the name of the architecture in some
cases (such as ppc64le vs ppc64) meson doesn't do this. It's worth
noting this in the documentation.
Instead of trying to hardcode which versions of which OSes are
misconfiguring llvm-config, lets try to use a generic mechanism that
catches most of the broken cases.
If a dynamic lib is built but the tools are linked staticly
(LLVM_BUILD_LLVM_DYLIB=true and LLVM_LINK_LLVM_DYLIB=false) and you
don't enabled shared libs (LLVM_BUILD_SHARED_LIBS=false, which should be
false), then llvm-config will mistakenly return a each static library
with .(so|dll|dylib) appended, instead of -lLLVM-x.y.z. if
LLVM_LINK_LLVM_DYlIB is true this works fine. There's been a bug opened
in upstream since 2014 about this with no responses[1].
So, this patches looks at --shared-mode (which tells us whether
llvm-config was linked staticly or dynamicly), then if the shared-mode
is static it will check and see what it gets. If it gets valid results
then it will go with those, if it doesn't then it will try to build a
set of valid link arguments to link with libLLVM.(so|dll|dylib).
[1] https://bugs.llvm.org/show_bug.cgi?id=19937
The versions of LLVM provided by brew have the same configuration problem that
dragonflyBSD and FreeBSD do, which means that they produce wrong results for
shared linking.
When passing static libraries to gtkdoc, they are also appended as
shared libraries to ldflags, which makes the process to fail.
This has been changed to only append shared libraries to ldflags.
Fixes#3935
Otherwise if we for some reason get '/usr/lib/../lib' in there
we end up saying it is not a system path.
And for some reason here I got:
```
$ pkg-config --libs libffi 148 ST 117 hotdoc
-L/usr/lib/../lib -lffi
```
Having a period at the end of sentences in messages is confusing when
a file or path is being outputted, and is inconsistent when not.
This is part of an ongoing effort to fix this inconsistency across the
message outputs everywhere in Meson.
Using the -pthread argument is not needed with clang when compiling for
darwin, and it results in the warning:
warning: argument unused during compilation: '-pthread'
GNU binutils ld silently ignores -rpath flags when targeting windows
(and it is already commented within ninjabackend.py that rpath as
concept doesn't exist on windows), and build_rpath_args in
VisualStudioCCompiler also returns an empty array. Therefore skip
this flag altogether.
This fixes linking with lld in MinGW mode, which doesn't support the
rpath flag.
This is a regression in Meson 0.48.0, commit 674ae46, Meson used to
exit(0) when running setup command in a builddir already configured.
Changing to exit(1) breaks some build tools that does "meson builddir
&& ninja -C builddir".
Closes#4247.
--as-needed controls ELF-specific functionality (the emission of DT_NEEDED
tags)
--no-undefined is effectively always on for PE/COFF, as the linkage model
always requires symbols to be defined
binutils ld silently ignores these flags for PE targets, but lld warns that
it's ignoring them, so just don't bother emitting them for PE targets.
Bruce Richardson
Jussi Pakkanen
Dylan Baker
Martin Storsjö
Guillermo Ignacio Enriquez Gutierrez
Kostiantyn Ponomarenko
Iñigo Martínez
Salamandar
Xavier RENE-CORAIL
Thibault Saunier
Nirbheek Chauhan
Marvin Scholz
Ross Burton
Ari Vuollet
GoaLitiuM
lzutao
Masanori Kakura
Marco Trevisan (Treviño)
Xavier Claessens
Jon Turney
Alexey Brodkin