| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Add support for the TASKING compiler family, and its MIL linking feature
|
|
|
|
Rust edition 2024 is being released in February, add support for rust_std=2024.
Resolves: #14074
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This is a better and more backwards-compatible way to disable all warnings,
compared to "-A warnings". The Rust RFC (https://rust-lang.github.io/rfcs/1193-cap-lints.html)
explains the rationale:
> We would very much like to be able to modify lints, however. For example
> rust-lang/rust#26473 updated the missing_docs lint to also look for missing
> documentation on const items. This ended up breaking some crates in the
> ecosystem due to their usage of #![deny(missing_docs)].
While at it, document that Rust deviates from the other languages in its
interpretation of warning_level=0.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
|
|
|
|
is_source() is called almost 900000 times in a QEMU setup. Together with
the previously added caching, this basically removes _determine_ext_objs()
from the profile when building QEMU.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
|
|
When followed by a comma, we can be absolutely sure that these are
argument prefixes, and will not consume the next argument to form
a single argument. Fixes spammy warnings on apple clang:
`ld: warning: duplicate -rpath 'build/dist/darwin_universal/arm64/lib/pkgconfig/../../lib' ignored`
Continuation from https://github.com/mesonbuild/meson/pull/13819
|
|
This was already done for dedup2_prefixes, also do it for
dedup1_prefixes, and move export-dynamic to dedup1_args, where it
belongs.
Also modify some comments around this to clearly distinguish
standalone argument matching and argument-prefix matching.
|
|
`-fuse-ld=` is a driver option for selection of a linker; it shall not be
passed to a linker with `-Wl,`.
For the Microsoft compiler and linker, the options for the compiler and those
for the linker are separated by `/LINK`, which looks like `cl /cl-options ...
/link /link-options ...`. Formally, they are passed in the same command line.
When Clang is invoking the Microsoft linker or a Microsoft-style linker (that
is, LLD-LINK), every linker option has to prefixed by `-Wl,` or `-Xlink`.
Previously, using Clang-CL and LLD-LINK, given:
cc = meson.get_compiler('c')
assert(cc.has_link_argument('/LTCG'))
This code failed to detect the `/LTCG` option, because `-fuse-ld=lld` was
passed to the linker, as an invalid option:
Command line: `clang E:\lh_mouse\Desktop\t\build\meson-private\tmpg0221fee\testfile.c -o E:\lh_mouse\Desktop\t\build\meson-private\tmpg0221fee\output.exe -D_FILE_OFFSET_BITS=64 -O0 -Werror=implicit-function-declaration -Wl,-WX -Wl,/LTCG -Wl,-fuse-ld=lld` -> 4044
stdout:
LINK : warning LNK4044: unrecognized option '/fuse-ld=lld'; ignored
LINK : error LNK1218: warning treated as error; no output file generated
However, it should be noted that not all LINK options can be passed with
`-Wl,`. The `/subsystem:windows,6.1` option has a comma, which would be
converted to a space. Therefore, this option must be passed as
`-Xlinker -subsystem:windows,6.1`. This issue is not addressed in this commit.
Signed-off-by: LIU Hao <lh_mouse@126.com>
|
|
clippy-driver is not meant to be a general-purpose compiler front-end.
Since Meson can now provide natively the ability to invoke clippy,
raise a warning if someone uses it that way.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Similar to the "ninja scan-build" target for C, add a clippy internal
tool that runs clippy-driver on all crates in the project.
The approach used is more efficient than with "ninja scan-build", and
does not require rerunning Meson in a separate build directory; it
uses the introspection data to find the compiler arguments for the
target and invokes clippy-driver with a slightly modified command
line.
This could actually be applied to scan-build as well, reusing the
run_tool_on_targets() function.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
It is useful to apply a limit to the number of processes even outside "meson test",
and specifically for clang tools. In preparation for this, generalize
determine_worker_count() to accept a variable MESON_NUM_PROCESSES instead of
MESON_TESTTHREADS, and use it throughout instead of multiprocessing.cpu_count().
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Recently, it is possible to install Clang with Visual Studio Installer. By
default this Clang has a MSVC target, and invokes the Microsoft Linker; if
`-fuse-ld=lld` is specified, it will invoke LLD-LINK. Both linkers take
MSVC-style arguments, and take DEF files with `/DEF:<path>`.
Previously DEF files were passed in the GNU way, directly on the linker
command line like an object file, which caused errors like
lld-link: error: ..\my.def: unknown file type
While Clang-CL takes Unix-style options, it actually passes MSVC-style
options to LINK or LLD-LINK with `-Wl,`. There is already a check for both
linkers in `linker_to_compiler_args()`, so it's necessary to do the same
in `gen_vs_module_defs_args()`.
This commit closes https://github.com/mesonbuild/meson/issues/13988.
Signed-off-by: LIU Hao <lh_mouse@126.com>
|
|
|
|
Using a rustup-based toolchain fails the "rust/2 sharedlib" test for me:
./prog: error while loading shared libraries: libstd-211931512faabf29.so: cannot open shared object file: No such file or directory
This happens because recent rustup places the standard library under
SYSROOT/lib/rustlib/TARGET/lib. Retrieve the right directory using
"--print target-libdir". This also provides a more accurate version
for rustc installed in /usr.
Before:
$ echo $(/usr/bin/rustc --print sysroot)/lib
/usr/lib
After:
$ /usr/bin/rustc --print target-libdir
/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib
While at it, cache the value to avoid repeated process invocation.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
version_compare can take a few milliseconds. If you have a thousand object files
or a multiple thereof, it adds up.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
|
|
This reverts commit 8242187eb06adaabbd9c9dbb6e5d9a8c102ee6a2.
This same change was previously introduced in #12495 / commit
30ab9747ae03364ac2ccd4a8f508286c57ed54a5 and subsequently reverted
in #12672 / commit 2fbc7b5ce3aced483b196dd10ca9eee1713b7494
Reintroduced in #13819 but it's still the same old problem. To repeat
the problem:
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
```
Today we have CI for this so the change actually caused our own unittest
CI to go red.
|
|
This fixes spammy warnings on apple clang:
ld: warning: duplicate -rpath 'build/dist/darwin_universal/arm64/lib/pkgconfig/../../lib' ignored
|
|
Fix TI C2000 support
|
|
The output_is_64bit, sizeof, cross_sizeof, compute_int and cross_compute_int
methods are reimplemented for Fortran compilers. Those inherited from
CLikeCompiler do not work since they assume C or C++.
Note that those tests rely on Fortran 2008 features (notably the c_sizeof
operator).
Closes #12757
|
|
Remove trailing periods for consistency with other option descriptions, and use
a consistent description for `winlibs` options everywhere (the one in the
documentation).
|
|
|
|
fixes #13271
|
|
|
|
The first versions of Emscripten that correspond with the Clang version
Meson uses to determine flag support don't actually support the expected
flags. So I went through and picked the first version that actually
worked with the expected flags.
Fixes #13628
|
|
These are all supported by GCC: https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Overall-Options.html
|
|
This is never set outside the `Compiler.__init__`, only added to. As
such there's no reason to have this `hasattr` check. It's wasting time
*and* confusing our static checkers.
|
|
This is used in exactly two cases, and it's just not worth it. Those two
cases can override the default set of extensions, and in the process
allow a nice bit of code cleanup, especially toward type checking.
|
|
|
|
Clang's resource files, e.g. /usr/share/clang/clang++.cfg, can be used to bump the default standard level across the system.
However due to llvm/llvm-project#61641 `clang++ -std=c++17 -E -dM -` doesn't work. The workaround is to pass the language explicitly.
4ad792e158b6059eb847dd0562aff9bd7029981f fixed the issue by passing the language explicitly, but started passing the `-cpp` flag, which Clang doesn't support.
Basically Clang would always fallback to the second detection attempt as a result. Remove the unsupported flag and the above scenarios works now too. 🙂
See-also: https://github.com/llvm/llvm-project/issues/61641
Fixes: 4ad792e158b6059eb847dd0562aff9bd7029981f
|
|
The "on" option is documented as passing the warning flags to all
subtools, and implies "most".
The default in the majority of projects is -warnings on,nocmdline, which
I'd take to be the equivalent of -Wall -Wextra, there isn't really an
inbetween.
|
|
|
|
project/target
Sanity check for bare metal rust wasn't working for a while and there is a pending PR (#12175).
To workaround this problem, we used to let sanity check for build machine and manually defined
rustc target.
Commit 18f8aeda8b59a132f24fa1af800ff65cac2f61f4 breaks this workaround as, even without an
exe_wrapper, native_static_libs are appends as internal deps.
This behaviour makes sense for cross compiled rust in a rich environment but not any for
no-std rust. As said in comments, one can't tell if the code is no-std or not because this is
an annotation from sources. From our point of view, it is pretty clear that building a no-std
rust target means that one has to define system='bare metal' and kernel='none' in his cross-file.
According to that, sanity_check for rust compiler is modified to handle kernel == 'none' case
by building a specific no-std rust snippet, with an extra args if rust_ld is ls.bfd (in order
to prevent the linker to link with a potentially non existing startfile for the given target).
'native_static_libs' is also leave empty in that very case.
This commit fix the spurious native static libs for no-std case and allow us to remove
our dirty workaround which by-passed non working sanity check for bare metal rust.
One who wants to use meson for baremetal Rust project only have to define the rust target
in their cross file.
e.g.
rust = ['rustc', '--target', '<rustc valid target>']
|
|
When running in some settings, a C compiler may demand newlines at the
end of each file. Instead of modifying everywhere that writes out test
files to incorporate newlines in each indivudual string, simply add a
newline when writing it out.
Only add a newline to the end of the file if there isn't one already
there.
An examples of when this is a problem is running with `CC=clang` and
`CFLAGS="--std=c99 -pedantic-errors"` and meson.build contains (for
example) the following:
```
project('myproject', 'c')
executable('myexecutable', 'main.c')
cc = meson.get_compiler('c')
sizeof_int = cc.sizeof('int')
```
sizeof_int will be -1, because the compile failed. The meson logs
contain the error `testfile.c:7:10: error: no newline at end of file`
|
|
We always pass the string value of the mode to determine_args, which
causes the check on the mode argument inside determine_args to always
evaluate to false.
Fix this by passing the mode itself, not its value.
|
|
These errors can make reading comments and documentation
unnecessarily confusing for users and contributors who
do not speak English as their first language.
|
|
|
|
Otherwise, `CFLAGS='-Wall -Werror' meson build` can fail detection:
Running compile:
Working directory: ./project/build/meson-private/tmpk86bgc04
Code:
#include <sys/types.h>
void bar(void) {
sizeof(loff_t);
}
-----------
Command line: `cc ./project/build/meson-private/tmpk86bgc04/testfile.c -o ./project/build/meson-private/tmpk86bgc04/output.obj -c -Werror -Wall -D_FILE_OFFSET_BITS=64 -O0 -std=gnu99` -> 1
stderr:
./project/build/meson-private/tmpk86bgc04/testfile.c: In function 'bar':
./project/build/meson-private/tmpk86bgc04/testfile.c:3:13: error: statement with no effect [-Werror=unused-value]
3 | sizeof(loff_t);
| ^~~~~~
cc1: all warnings being treated as errors
-----------
Checking for type "loff_t" : NO
|
|
Otherwise, `CFLAGS='-Wall -Werror' meson build` can fail detection:
void bar(void) {
struct stat foo;
foo.st_mtim.tv_nsec;
}
-----------
Command line: `cc ./project/build/meson-private/tmpqz_gi65d/testfile.c -o ./project/build/meson-private/tmpqz_gi65d/output.obj -c -O3 -Werror -Wall -D_FILE_OFFSET_BITS=64 -O0 -std=gnu99` -> 1
stderr:
./project/build/meson-private/tmpqz_gi65d/testfile.c: In function 'bar':
./project/build/meson-private/tmpqz_gi65d/testfile.c:45:24: error: statement with no effect [-Werror=unused-value]
45 | foo.st_mtim.tv_nsec;
| ~~~~~~~~~~~^~~~~~~~
cc1: all warnings being treated as errors
|
|
LDFLAGS may contain flags that nvcc is unable to handle and these flags
need to be processed before we pass them to nvcc
|
|
Enables lto & thinlto support for clang-cl when used with lld-link.
|
|
|
|
|
|
"swiftc -Xlinker -v tmp.swift" command used to detect swift linker
creates junk files in working directory. This fix forwards output to
/dev/null
|
|
Meson accidentally strips '-isystem' from C build args like ['-isystem',
'/path/to/headers'] if the compiler includes the current working directory
in the header search paths. The root cause is that '-isystem'[8:] evaluates
to an empty string and os.path.realpath('') returns the absolute path to
the current working directory, causing meson to think that '-isystem'
specifies a default include path.
Different compiler versions varies whether the current working directory is
in its search paths. For example, on Ubuntu 21.04:
# gcc -xc -v -E -
gcc version 10.3.0 (Ubuntu 10.3.0-1ubuntu1)
#include "..." search starts here:
#include <...> search starts here:
.
/usr/lib/gcc/x86_64-linux-gnu/10/include
/usr/local/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
While on Ubuntu 24.04:
# gcc -xc -v -E -
gcc version 13.2.0 (Ubuntu 13.2.0-23ubuntu4)
...
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-linux-gnu/13/include
/usr/local/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
Do not check the '-isystem=' and '-isystem/path/to/header' cases when the
option is '-isystem' but the path that follows is not a default search
path.
Signed-off-by: Junjie Mao <junjie.mao@hotmail.com>
|
|
Co-Authored-By: L. E. Segovia <amy@amyspark.me>
|
|
This allows to get this fixed value before the class is initialized.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
|
|
In particular, it is only ever constructed once, and all but two of its
arguments are always passed. So there's no reason or valid justification
to initialize them as None or pretend that you have to check them for
None values. Nor in fact does the command list need to be a
default_factory.
There are also two instance attributes which it is never instantiated
with, but which are tracked after the fact. Don't add this to the
signature for `__init__` as that is misleading.
|
|
None sentinel is replaced by field(), so we don't need to declare it
Optional anymore.
|
