| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
Fallout from the OptionStore refactor, and specifically commit
9a6fcd4d9a0c7bb248c5d0587632b741a3301e03. The `std` object was migrated
from having an option itself, to having the value fetched and saved
directly. In most cases, this also meant avoiding `.value`, but in a
couple cases this refactor went overlooked, and crashed at runtime.
Only affects Elbrus and Intel C++ compilers, seemingly.
Fixes #13401
|
|
For other reasons, Meson transforms "-Wno-x" into "-Wx -Wno-x" for GCC,
but this breaks with "-Wno-attributes=x" with:
```
cc1plus: error: arguments ignored for '-Wattributes='; use '-Wno-attributes=' instead
```
Suppress that workaround for -Wno-attributes=.
Closes: https://github.com/mesonbuild/meson/issues/13022
|
|
|
|
In 8d7ffe6e863834f0190e need_exe_wrapper() use was copied which was just reverted,
so replace with is_cross there too, to keep things in sync.
|
|
c1076241af11f10acac28d771688bb54c6b0b340 changed the logic in multiple
places, in particular it looks like it was assumed that is_cross is always
the same as need_exe_wrapper(), but that's not true.
Also the commit only talks about mypy, so this was definitely not intended.
This reverts all the cases where need_exe_wrapper() was introduced back to
is_cross.
The change in backends.py could be a correct simplification, but I don't know
the code base enough, so reverting that too.
See #13403 and #13410
|
|
The public facing name of language options is compiler option, so
let's standardise on that.
|
|
|
|
Fixes building Nasm objects with Meson's native language support, when
depending against a library that exports that flag, like Glib.
|
|
Which requires injecting some extra paths and the `-Xpreprocess` flag,
as well as extra search paths for libomp and the headers.
Fixes: #7435
|
|
And into the Clang-CL mixin.
|
|
This will be needed by the Apple compiler
|
