We need to support cases where the library might be called "foo.so" and
therefore we check for exact matches too. But this also allows
`cc.find_library('libfoo')` to find libfoo.so, which is strange and
won't work in many cases. Emit a warning when this happens.
Fixes#10838
We *mostly* just need to do the same thing. Plug in one utility method
to make sanity_check_impl find the right compile args, and plug in
DEVNULL to the test run. It's that simple.
This solves a few inconsistencies. The main one is that fortran never
logged the sanity checks to the Meson debug log, making it hard to
debug.
There's also some interesting quirks we built up in the dedicated
fortran handling. For example:
- in commit 5b109c9ad2 we added cwd to
building the fortran executable, with a wordy comment about how the
compiler has defects. But the clike base has always done that on
general principle anyway, so we would never have had that bug in the
first place.
- in commit d6be7822a0 we added special
deletion of an old "bad existing exe file" just for fortran. Looking
at the PR discussion for this odd requirement, it turns out that the
real problem is mixing WSL and native Windows without deleting the
build directory. This is apparently fortran specific simply because
"contemporary Windows 10 Fortran users" switch between the two?
The actual problem is that this never used .exe as the output name, so
Windows thinks you want to run something other than the thing you
asked to run, because it's not even a Window executable. But... the
common clike handling could have fixed that without needing special
cases.
Specifically, this is a combination of the following:
- Revert "visualstudio.py: Apply /utf-8 only on clang or VS2015+"
This reverts commit 6e7c3efa79.
- Revert "Visual Studio: Only use /utf-8 on VS2015 or later or clang-cl"
This reverts commit 8ed151bbd7.
The changes were broken and untested, although this is because of a lack
of general CI testing for all languages on Windows. At least, this broke
the use of ifort, and possibly more.
The changes are fundamentally a bit "exciting", as they step out of the
hierarchy of compiler definitions and apply arguments almost willy-nilly.
And apparently it's leaky all over the place. I don't understand all of
what is going on with it, but it plainly failed to achieve its desired
goal and needs to be rolled back ASAP.
In PR 10263, we didn't account for that we may have initialize the Visual
Studio-like compiler two times, once for a C compiler and once for the
C++ compiler, so we end up with Meson breaking on Visual Studio 2013
or earlier, such as when building GLib.
Fix this by setting up the always_args member of
the VisualStudioLikeCompiler instance during __init__() as needed, so that
we avoid falling into modifying shared objects.
This option is only valid for C++ and ObjC++, but the kwarg is useful
for mixed language targets. Asking for inlines as well, when the
compiler driver is trying to build the C components of a target, results
in gcc emitting:
```
cc1: warning: command-line option ‘-fvisibility-inlines-hidden’ is valid for C++/ObjC++ but not for C
```
Squelch this warning by filtering it out on Meson's side of things.
[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>
The compiler flag only exists on Visual Studio 2015 or later, or clang-cl,
and using this always can interfere with compiler feature detection when
this flag is not supported.
So, remove '/utf-8' from always_args if we are on Visual Studio 2013 or
earlier.
This has been broken ever since the original implementation. Due to a
typo, the optimization flag used a zero instead of an uppercase "o",
which the compiler then breaks on during argument parsing because it is
an invalid argument.
Fixes#10267
When something goes wrong with running the compiler in
_symbols_have_underscore_prefix_searchbin, print stderr instead,
as it actually contains helpful output while stdout is usually empty
in this case.
Fixes the following ResourceWarnings:
ResourceWarning: subprocess 25556 is still running
_warn("subprocess %s is still running" % self.pid,
ResourceWarning: Enable tracemalloc to get the object allocation traceback
mesonbuild/compilers/mixins/gnu.py:195: ResourceWarning: unclosed file <_io.BufferedReader name=4>
return gnulike_default_include_dirs(tuple(self.exelist), self.language).copy()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
It is always used as an immutable view so there is no point in doing
copies. However, mypy insist it must implement the same APIs as
Dict[OptionKey, UserOption[Any]] so keep faking it.
GCC with optimization set to 0 does not actually result in no
optimizations, which can be annoying when trying to use a debugger like
gdb, and finding that your variable has been optimized out. We already
do this with clang, so gcc is a bit of an outlier here.
Removed errant "type: ignore".
Fixed issue with "fetch" call. This issue was the following:
Dict::get() and Dict::pop() have the following signature:
T.Callable[[_T, _U], _U | None] OR T.Callable[[_T], _U | None]
Note how the return type is _U here. When the fetch() function was
actually being called, it had the following signature:
T.Callable[[_T, T.List[_U]], T.Union[T.List[_U], _U]]
This is incompatible with the previous definitions. The solution is
simply to move where the default value is introduced if fetch() produces
None.
If the LTO threads == 0 clang will default to the same argument we
manually pass, which meant we dropped support for admittedly ancient
versions of clang that didn't yet add that option.
Drop the extraneous argument, and add a specific error condition when
too old versions of clang are detected.
Fixes#9569
-Oz is the appropriate flag to use when you want to produce the smallest
possible binary, and is one would expect when setting optimization to s
or using the minsize build type.
* compilers: improve docstring to `get_compiler_check_args()`
There was an incomplete list, which wasn't useful as it now takes an
enum anyway. Also add a new entry to the list of reasons to use this
function.
* clang: Add -Werror=implicit-function-declarations to check_args
Unlike GCC, clang warns but doesn't error when an implicit function
declaration happens. This means in checks like
`compiler.has_header_symbol('string.h', 'strlcat')` (on Linux, at least)
that GCC will fail, as there is no such function; clang will emit a
warning, but since it exists with a 0 status Meson interprets that as
success. To fix this, add `-Werror=implicit-function-declarations` to
clang's check arguments.
There seems to be something specific about functions that _may_ exist in
a header on a given system, as `cc.has_header_symbol('string.h',
'foobar')` will return false with clang, but `strlcat` will return true,
even though it's not defined. It is however, defined in some OSes, like
Solaris and the BSDs.
Fixes#9140
We have a lot of these. Some of them are harmless, if unidiomatic, such
as `if (condition)`, others are potentially dangerous `assert(...)`, as
`assert(condtion)` works as expected, but `assert(condition, message)`
will result in an assertion that never triggers, as what you're actually
asserting is `bool(tuple[2])`, which will always be true.