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.
Store the MSVC compiler target architecture ('x86', 'x64' or 'ARM' (this
is ARM64, I believe)), rather than just if it's x64 or not.
The regex used for target architecture should be ok, based on this list
of [1] version outputs, but we assume x86 if no match, for safety's
sake.
[1] https://stackoverflow.com/a/1233332/1951600
Also detect arch even if cl outputs version to stdout.
Ditto for clang-cl
Future work: is_64 is now only used in get_instruction_set_args()
This allows each implementation (gnu-like) and msvc to be implemented in
their respective classes rather than through an if tree in the CCompiler
class. This is cleaner abstraction and allows us to clean up the Fortran
compiler, which was calling CCompiler bound methods without an instance.
ICC doesn't use the same -fprofile-generate/-fprofile-use that GCC and
Clang use, instead it has -prof-gen and -prof-use. I've gone ahead and
added the threadsafe option to -prof-gen, as meson currently doesn't
have a way to specify that level of granularity and GCC and Clang's
profiles are threadsafe.
Because we need to inherit them in some cases, and python's
keyword-or-positional arguments make this really painful, especially
with inheritance. They do this in two ways:
1) If you want to intercept the arguments you need to check for both a
keyword and a positional argument, because you could get either. Then
you need to make sure that you only pass one of those down to the
next layer.
2) After you do that, if the layer below you decides to do the same
thing, but uses the other form (you used keyword by the lower level
uses positional or vice versa), then you'll get a TypeError since two
layers down got the argument as both a positional and a keyword.
All of this is bad. Fortunately python 3.x provides a mechanism to solve
this, keyword only arguments. These arguments cannot be based
positionally, the interpreter will give us an error in that case.
I have made a best effort to do this correctly, and I've verified it
with GCC, Clang, ICC, and MSVC, but there are other compilers like Arm
and Elbrus that I don't have access to.
It seems that clang-cl isn't quite compatible with cl in the way it handles
pch, and when the precompiled header is used, the pathname of the header is
needed, not just its filename.
This fixes test\common\13 pch with clang-cl
When invoked as clang-cl to compile, it doesn't emit cl-compatible D9002
warnings about unknown options, but fortunately also supports
-Werror-unknown-argument instead.
When invoked to link, and using LINK, it does emit cl-compatible LNK4044
warnings about unknown options.
Currently, ComplierHolder.determine_args() unconditionally adds the link
arguments to the commmand, even if we aren't linking, because it doesn't
have access to the mode (preprocess, compile, link) that
_get_compiler_check_args() will use.
This leads to command lines like:
'cl testfile.c /nologo /showIncludes /c /Fooutput.obj /Od kernel32.lib
user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib
uuid.lib comdlg32.lib advapi32.lib'
which clang-cl considers invalid; MSVS cl accepts this, ignoring the
unneeded libraries
Change from passing extra_args down to _get_compiler_check_args(), to
passing down a callback to CompilerHolder.determine_args() (with a bound
kwargs argument), so it can consult mode and kwargs to determine the args to
use.
Handle clang's cl or clang-cl being in PATH, or set in CC/CXX
Future work: checking the name of the executable here seems like a bad idea.
These compilers will fail to be detected if they are renamed.
v2:
Update compiler.get_argument_type() test
Fix comparisons of id inside CCompiler, backends and elsewhere
v3:
ClangClCPPCompiler should be a subclass of ClangClCCompier, as well
Future work: mocking in test_find_library_patterns() is effected, as we
now test for a subclass, rather than self.id in CCompiler.get_library_naming()
Some compilers try very had to pretend they're another compiler (ICC
pretends to be GCC and Linux and MacOS, and MSVC on windows), Clang
behaves much like GCC, but now also has clang-cl, which behaves like MSVC.
This method provides an easy way to determine whether testing for MSVC
like arguments `/w1234` or gcc like arguments `-Wfoo` are likely to
succeed, without having to check for dozens of compilers and the host
operating system, (as you would otherwise have to do with ICC).
Replace several checks against GCC_MINGW or (GCC_MINGW, GCC_CYGWIN) with
is_windows_compiler instead, so that clang and other gcc-like compilers
using MinGW work appropriately with vs_module_defs, c_winlibs, and
cpp_winlibs.
Fixes#4434.
This allows using the imperfect profiles generated by multithreaded
programs. Without the argument, GCC fails to load them.
Clang just ignores the argument AFAICT.
Fixes https://github.com/mesonbuild/meson/issues/2159
For PE/COFF it is not possible to allow undefined symbols, so do not
try to use the option to do so.
While gcc ld silently ignores it, this is not the case for the llvm
linker.
Fix#4415
* This helps with reproducibility on macOS in the same way
`$ORIGIN` improves reproducibility on Linux-like systems.
* This makes the build-tree more resilient to users injecting
rpaths via `LDFLAGS`. Currently Meson on macOS crashes when
a build-tree rpath and a user-provided `-Wl,-rpath` in
LDFLAGS collide, leading to `install_name_tool` failures.
While this still does not solve the root cause, it makes
the occurrence much less likely, as users will generally
pass absolute `-Wl,-rpath` arguments into Meson.
Occasionally Darwin libraries can be .so rather than .dylib e.g. tensorflow_cc.so
tensorflow_cc is a c++ API for Tensorflow (https://github.com/FloopCZ/tensorflow_cc)
which was primarily written for Linux but is also compilable on Darwin. Possibly
through laziness, possibly just to have consistent filenames, the developers did not
opt to change the suffix from the Linux default when this is compiled on Darwin.
Also, the Darwin linker will find libraries with a .so suffix if they are
in its path. find_library() needs to match the linker behaviour.
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.
Jon Turney
John Ericson
Jussi Pakkanen
Dylan Baker
Martin Storsjö
Phillip Cao
Josh Gao
Jan Alexander Steffens (heftig)
Nicole Mazzuca
pbl
Marvin Scholz
Xavier Claessens
David Seifert
gsobala
Matthias Klumpp
Mohammed Amer Khalidi
Bruce Richardson