intel compiler's defaults are different enough from MSVC and GNU
that it's necessary to set specific defaults for Intel compilers.
This corrects/improves behaviors initially addressed in b1c8f765fa
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
Some slight refactoring for the dependency classes and
I switched the elbrus compiler to the GnuLikeCompiler.
This is also the correct use according to the documentation
of GnuLikeCompiler.
This puts appropriate default options across buildtype for Intel and
Intel-Cl compilers, for C, C++ and Fortran. Prior to this PR, the
behavior of Intel compilers vs. GNUlike was not the same, in
particular, debug traceback available by default for GNUlike compilers
was not present with Intel compilers.
compiler.get_supported_arguments reports success for certain unsupported
flags when using the gnu C/ObjC, C++/ObjC++ compilers. This fix reads
the stderr on the has_arguments check to ensure the arguments really are
supported and not valid for the language selection
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.
To make Fortran tests useful on Windows, the library_type should default to static,
unless needed to specifically test shared. Shared Fortran libs on Windows for
non-Gfortran compilers is fragile requiring proprietary code syntax.
* PGI C++ PCH enable
PGI compilers support precompiled headers for C++ only.
The common/13 pch test passes if run manually with no spaces in the build path.
However, since Meson run_project_tests.py makes temporary build directories
with spaces in each tests, PGI --pch_dir can't handle this and fails.
So we skip the test for PGI despite it working for usual case with no-spaces
in build dir.
Note: it's fine to have spaces in full path for sourcedir, just no spaces in
relative path to builddir.
* doc
There are two problems, one is that it assumes -flto is the argument
to do LTO/WPO, which isn't true of ICC and MSVC (and presumably)
others. It's also incorrect because it assumes that the compiler and
linker will always be the same, which isn't necessarily true. You
could combine GCC with Apple's linker, or clang with link.exe, which
use different arguments.
Error example:
Code:
#include <locale.h>
int main () {
/* If it's not defined as a macro, try to use as a symbol */
#ifndef LC_MESSAGES
LC_MESSAGES;
#endif
}
Compiler stdout:
Compiler stderr:
In file included from /usr/include/locale.h:25,
from /tmp/tmpep_i4iwg/testfile.c:2:
/usr/include/features.h:382:4: warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Wcpp]
382 | # warning _FORTIFY_SOURCE requires compiling with optimization (-O)
| ^~~~~~~
/tmp/tmpep_i4iwg/testfile.c: In function 'main':
/tmp/tmpep_i4iwg/testfile.c:8:9: error: control reaches end of non-void function [-Werror=return-type]
8 | }
| ^
cc1: some warnings being treated as errors
Daniel Mensinger
Michael Hirsch, Ph.D
Dylan Baker
Xavier Claessens
Michael Hirsch, Ph.D
Wolfgang Stöggl
Aleksey Gurtovoy
makise-homura
Andrei Alexeyev
Michael Lenczewski
Jehan
Phillip Cao
Jussi Pakkanen
Martin Liska