Currently both print `Detecting linker via`, which can be confusing.
Clarifying this by printing "archiver" instead of "linker" for the
static linker/archiver
With LTO, the linker will re-execute the compiler and various warnings may
be emitted. We must therefore pass -Werror to the linker as well when -Werror
is enabled to capture these. This is only required / useful with LTO.
Closes: https://github.com/mesonbuild/meson/issues/7360
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
For Clang, we now pass -D_GLIBCXX_DEBUG=1 if debugstl is enabled, and
we also pass -D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_DEBUG.
Per https://discourse.llvm.org/t/building-a-program-with-d-libcpp-debug-1-against-a-libc-that-is-not-itself-built-with-that-define/59176/3,
we can't use _LIBCPP_DEBUG for older Clang versions as it's unreliable unless
libc++ was built with it.
We choose MODE_DEBUG for stldebug while building with assertions will do
MODE_EXTENSIVE.
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
None of the options set here affect ABI and are intended for detecting constraint
violations.
For GCC, we simply need to set -D_GLIBCXX_ASSERTIONS.
For Clang, the situation is far more complicated:
* LLVM 18 uses a 'hardened mode' (https://libcxx.llvm.org/Hardening.html).
There are several levels of severity available here. I've chosen
_LIBCPP_HARDENING_MODE_EXTENSIVE as the strongest-but-one. The strongest
one (_DEBUG) doesn't affect ABI still but is reserved for stldebug.
* LLVM 15 uses a similar approach to libstdc++ called '_LIBCPP_ENABLE_ASSERTIONS'
Note that LLVM 17 while in development had fully deprecated _LIBCPP_ENABLE_ASSERTIONS
in favour of hardened, but changed its mind last-minute: https://discourse.llvm.org/t/rfc-hardening-in-libc/73925/4.
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
This reverts commit 53ea59ad84.
This breaks at least:
- frameworks/17 mpi
- frameworks/30 scalapack
The problem is that openmpi's pkg-config emitted link arguments
includes:
```
-Wl,-rpath -Wl,/path/to/libdir
```
The deduplication logic in meson doesn't contain sufficient information
to tell when the compiler is passing an argument that requires values,
and definitely cannot tell when that argument is split across argv. But
for arguments that *can* do this, it is not possible to deduplicate a
single argument as standalone, because it is not standalone.
The argument for deduplicating rpath here was that if you have multiple
dependencies that all add the same rpath, the Apple ld64 emits a
non-fatal warning "duplicate -rpath ignored". Since this is non-fatal,
it's not a major issue. A major issue is when builds fatally error out
with:
```
FAILED: scalapack_c
cc -o scalapack_c scalapack_c.p/main.c.o -Wl,--as-needed -Wl,--no-undefined -Wl,--start-group /usr/lib64/libscalapack.so /usr/lib64/liblapack.so /usr/lib64/libblas.so -Wl,-rpath -Wl,/usr/lib64 -Wl,/usr/lib64 -Wl,--enable-new-dtags /usr/lib64/libmpi.so -Wl,--end-group
/usr/libexec/gcc/x86_64-pc-linux-gnu/ld: error: /usr/lib64: read: Is a directory
```
This replaces all of the Apache blurbs at the start of each file with an
`# SPDX-License-Identifier: Apache-2.0` string. It also fixes existing
uses to be consistent in capitalization, and to be placed above any
copyright notices.
This removes nearly 3000 lines of boilerplate from the project (only
python files), which no developer cares to look at.
SPDX is in common use, particularly in the Linux kernel, and is the
recommended format for Meson's own `project(license: )` field
no_warn_args is unused. Its only purpose was to implement automatic
hiding of UB in transpiled code, and it was not used at all in languages
other than C/C++ -- specifically when the C/C++ source files were
created by transpiling from vala or cython.
If an annotation could not be resolved, it's classified as a "missing
import" and our configuration ignored it:
```
Skipping analyzing "mesonbuild.backends": module is installed, but missing library stubs or py.typed marker
```
As far as mypy is concerned, this library may or may not exist, but it
doesn't have any typing information at all (may need to be installed
first).
We ignored this because of our docs/ and tools/ thirdparty dependencies,
but we really should not. It is trivial to install them, and then
enforce that this "just works".
By enforcing it, we also make sure typos get caught.
[why]
On Apple clang 15.0.0 linker (i.e. ld64 1015.7) giving the same rpath
multiple times raises a warning:
ld: warning: duplicate -rpath '/local/lib' ignored
This can frequently happen when linking several dependencies that all
have that rpath in e.g. pkgconfig.
[how]
Deduplicate all rpath arguments.
[note]
I'm not sure how the code handles --start/end-group, but for rpath that
should not make any difference as that is not bound to a group.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
has_function_attribute() depends on -Wattributes being emitted when an attribute
is not supported by the compiler. In case of GCC on Window (at least) there is no
warning in case the attribute is used on a declaration. Only once there is also a
function definition does it emit a warning like:
a.c: In function ‘foo’:
a.c:8:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]
8 | }
To fix this add a dummy function definition to all visibility compiler checks in meson.
The tests in "197 function attributes" only checked for positive return result on on-msvc
compilers, except one special case for dllexport/dllimport. Refactor the tests a bit so
one can specify also a negative expected result, and add tests for all visibility attribute
variants.
Partially reverts commit 1624354f33 which
moved a bunch of stuff from strings to enums. The issue here is that
Compiler.mode is not just, or primarily, something we compare, but is
instead written in as e.g. `rule c_{compiler.mode}` to build.ninja, so
this identifier needs to be a string.
Ultimately, the issue is that the commit tried to rewrite a bunch of
things called "mode" that had a couple of TODOs saying to use enums...
but it rewrote everything called "mode" regardless of whether it was a
function kwarg or a compiler property, even though the TODO only applied
to one of them.
The DCompiler and DmDLikeCompiler classes both implement the exact same
`get_feature_args()` method. The DmdLikeCompiler inherits the DCompiler.
As such, removing it doesn't change the behavior of anything, but
decreases the chances of bugs being introduced, as well as LoC.
The <lang>_stdlib can be used in cross files to use a custom standard library
for a given language.
When cpp_stdlib is used in a cross file, meson passes
* -nostdinc++ to the compiler
* -nostlib to the linker
According to [1] (gcc) and [2] (clang), we should pass -nostlib++ to the linker
when we don't want to link to the standard C++ library.
Currently, we pass -nostlib.
Fix this by implementing a C++ specific get_no_stdlib_link_args() function.
[1] https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#index-nostdlib_002b_002b
[2] https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-nostdlib
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
It should *be* a version comparison. We are guaranteed to get a
two-element version number, which also parses as a float but a float
doesn't correctly handle version sorting when the second component
differs in number of digits.
The standard way to handle this is by comparing tuples such that each
component is an integer. Do so here.
Fixes#12195
Co-authored-by: George Koehler <xkernigh@netscape.net>
(for unittests)
Needed a classpath set in the current working directory.
This was on a Zulu build of OpenJDK 11.0.17 on a macOS ARM machine.
The errors folks might encounter:
Error: Could not find or load main class SanityCheck
Caused by: java.lang.ClassNotFoundException: SanityCheck
c++26 support was added in #11986, but regressed in #10332 because
the versions now get checked against the global _ALL_STDS list, and
c++26 was missing there.
Fix by adding c++26 to _ALL_STDS
Pulled from this list on Xcode 15 beta:
$ clang -E -dM -xobjective-c++ -std=arglbargle -o - /dev/null
error: invalid value 'arglbargle' in '-std=arglbargle'
note: use 'c++98' or 'c++03' for 'ISO C++ 1998 with amendments' standard
note: use 'gnu++98' or 'gnu++03' for 'ISO C++ 1998 with amendments and GNU extensions' standard
note: use 'c++11' for 'ISO C++ 2011 with amendments' standard
note: use 'gnu++11' for 'ISO C++ 2011 with amendments and GNU extensions' standard
note: use 'c++14' for 'ISO C++ 2014 with amendments' standard
note: use 'gnu++14' for 'ISO C++ 2014 with amendments and GNU extensions' standard
note: use 'c++17' for 'ISO C++ 2017 with amendments' standard
note: use 'gnu++17' for 'ISO C++ 2017 with amendments and GNU extensions' standard
note: use 'c++20' for 'ISO C++ 2020 DIS' standard
note: use 'gnu++20' for 'ISO C++ 2020 DIS with GNU extensions' standard
note: use 'c++2b' for 'Working draft for ISO C++ 2023 DIS' standard
note: use 'gnu++2b' for 'Working draft for ISO C++ 2023 DIS with GNU extensions' standard
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
The Metrowerks assembler does not support optimization flags.
However, it received the same opt args as the Metrowerks C and C++
compilers, because it inherits from the 'MetrowerksCompiler' mixin.
This broke builds with opt level higher than 0 that used the Metrowerks
Assembler, as the latter received unsupported args. This is now fixed.
According to the Meson documentation, optimization level 3 should
set the highest possible optimization for the compiler in use.
In Metrowerks, this is 'O4,p'. However, Meson's Metrowerks
implementation mapped opt level 3 to '-O3'. This has been fixed.
The args were in both buildtype and optimization. This broke buildtypes other
than plain or custom unless manually setting the optimization level to
0, because Metrowerks chokes on duplicate arguments.
A standard C library may not exist for cross-compile
environments, thus the existence of <stdio.h> cannot be
guaranteed.
Use <stddef.h> instead, this header contains compiler-specific
defines thus it usually comes from the compiler.
Coredata is where all option handling is done so it makes sense there.
It is a view on a list of options for a given subproject and with
optional overrides. This change prepare for using that view in a more
generic way in the future.
Adds a new method to the compiler object, has_define.
This makes it possible to check if a preprocessor macro/define
is set or not.
This is especially helpful if the define in question is empty,
for example:
#define MESON_EMPTY_DEFINE
This would yield the same results as a missing define with
the existing get_define method, as it would return an empty
string for both cases. Therefore this additional method is
needed.
Performed using https://github.com/ilevkivskyi/com2ann
This has no actual effect on the codebase as type checkers (still)
support both and negligible effect on runtime performance since
__future__ annotations ameliorates that. Technically, the bytecode would
be bigger for non function-local annotations, of which we have many
either way.
So if it doesn't really matter, why do a large-scale refactor? Simple:
because people keep wanting to, but it's getting nickle-and-dimed. If
we're going to do this we might as well do it consistently in one shot,
using tooling that guarantees repeatability and correctness.
Repeat with:
```
com2ann mesonbuild/
```
clang has supported gcc syntax since version 3.3.0 from 10 years ago.
It's better than its own version because it takes a "when" verb which
allows us to explicitely ask for "auto". This is useful when overriding
flags that came from elsewhere.
Before this patch, meson was just treating b_colorout="auto" as "always".
Projects that prefer GNU C but can fallback to ISO C can now set for
example `default_options: 'c_std=gnu11,c11'` and it will use gnu11 when
available, fallback to c11 otherwise. It is an error only if none of the
values are supported by the current compiler.
This allows to deprecate gnuXX values from MSVC compiler, that means
that `default_options: 'c_std=gnu11'` will now print warning with MSVC
but still fallback to 'c11' value. No warning is printed if at least one
of the values is valid, i.e. `default_options: 'c_std=gnu11,c11'`.
In the future that deprecation warning will become an hard error because
`c_std=gnu11` should mean GNU is required, for projects that cannot be
built with MSVC for example.
Since it's deprecated anyway, we don't really want to plumb it all the
way down into the build and backend layers. Instead, we can just turn
it into a `win_subsystem` value in the interpreter if `win_subsystem`
isn't already set.
This detects cases where module A imports a function from B, and C
imports that same function from A instead of B. It's not part of the API
contract of A, and causes innocent refactoring to break things.
H. Vetinari
Dylan Baker
Sam James
Alyssa Ross
Simon Ser
wrvsrx
Eli Schwartz
Charles Brunet
Denis Drakhnia
Will Toohey
Fini Jastrow
Christoph Reiter
Aditya Vidyadhar Kamath
Eli Schwartz
Xavier Claessens
Mattijs Korpershoek
Benjamin Redelings
Marvin Scholz
Alan Brooks
Steven Noonan
Nomura
Moody Liu
Filipe Laíns
Benoit Pierre
kiwixz