| Age | Commit message (Collapse) | Author |
|
It really isn't a sanity check that a specific compiler doesn't work on
a specific platform. This re-implements the check as a shared component
in the ASMCompiler base class, which has the advantage of code sharing.
|
|
This will be able to hold some shared state between the different ASM
compilers (or should that be assemblers?)
|
|
|
|
This is used for project to require a nightly Rust compiler, and also
for Meson to enable nightly feature if available.
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This fixes the following error occured in the test 3 of the Emscripten
build.
> wasm-ld: error: unable to find library -llibvalue.a
Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>
|
|
Work around https://github.com/llvm/llvm-project/issues/129881.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Use the same check for all of clang, nasm and rustc.
This also avoids the following warning:
Sanity check compiler command line: clang++ sanitycheckobjcpp.mm -o sanitycheckobjcpp.exe -D_MT -D_DLL -D_DEBUG -D_FILE_OFFSET_BITS=64 -Wl,-fms-runtime-lib=dll_dbg Sanity check compile stdout:
LINK : warning LNK4044: unrecognized option /fms-runtime-lib=dll_dbg; ignored
iWhat happens is that -fms-runtime-lib sets up an automatic dependency
from the .o files to the final link product, and therefore must be
passed as a compiler argument. But the constructor for ClangCompiler
was incorrectly allowing b_vscrt for MINGW, so I messed up the logic.
With this change, MINGW won't get the b_vscrt option.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
|
|
On Windows, rustc searches both FOO.lib and libFOO.a when passed -lfoo.
This means that the check for nonstandard names in the Unix sense is
too struct, and indeed it breaks passing for example -lkernel32 (which
adds kernel32.lib to the link).
Fix this by special casing Windows. Extract the logic to the Rust
compiler class for clarity.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This reverts commit 1e254ad7f327e5ed2021463e4b66c37072d354e3.
|
|
This reverts commit be50d0e23737dc0fc5f074a291644d7fde39ef7b.
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
The two methods are identical.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This reverts commit 806289a5d27958a084bc6cba41b7cf9ccee4ecf4.
|
|
This reverts commit 8847c938dd1c9e2c6e64e3050eb58f7ec54fccb3.
|
|
This reverts commit 08221c6d1fc4a6afe780a479bbc7e40899242601.
|
|
and Linux"
This reverts commit c520e8981693056419d846f60ffb85061bf3191f.
|
|
This leaves other systems to be implemented, as I don't have a good way
of checking that they work correctly.
|
|
ASM has some special concerns because it has to be implemented in terms
of assembling an object, and then linking the object with a linker or
linker driver. That makes the implementation somewhat complex.
There is a bit of a hack going on here with the `_run_sanity_check`
method and the mro. I'm still thinking about how best to handle that.
|
|
Such as NASM and MASM. These compilers don't actually do any linking,
the just produce object files. As such, we need the C compiler to link
the program in order to make things like sanity_check work.
|
|
The goal is to reduce code duplication, and allow each language to
implement as little as possible to get good checking. The main
motivation is that half of the checks are fragile, as they add the work
directory to the paths of the generated files they want to use. This
works when run inside mesonmain because we always have an absolute build
directory, but when put into run_project_tests.py it doesn't work
because that gives a relative build directory.
|
|
It really isn't a sanity check that a specific compiler doesn't work on
a specific platform. This re-implements the check as a shared component
int he ASMCompiler base class, which has the advantage of code sharing
|
|
This will be able to hold some shared state between the different ASM
compilers (or should that be assemblers?)
|
|
Signed-off-by: Kushal Pal <kushpal@qti.qualcomm.com>
|
|
The main complication here is that passing -fms-runtime-lib during compilation
results in a warning:
clang: error: argument unused during compilation: '-fms-runtime-lib=dll' [-Werror,-Wunused-command-line-argument]
(https://github.com/mesonbuild/meson/actions/runs/17727020048/job/50369771571).
So, for compilation expand the -D flags by hand, and only pass -fms-runtime-lib
when linking.
Fixes: #14571
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
get_crt_link_args was only called for the final linker command line; add
its result to the sanity check and compiler tests as well.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Option values have type "str | int | list[str]", assert that they are
strings before passing them to self.get_crt_compile_args().
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
ccache has been for a long time compatible with MSVC (since 4.6)
but when using debug mode, the /Z7 flag must be passed instead of
/Zi.
See https://ccache.dev/releasenotes.html#_ccache_4_6
|
|
According to https://clang.llvm.org/docs/CommandGuide/clang.html#cmdoption-flto,
the -object_path_lto flag is needed to preserve the intermediate object
files.
|
|
Rust 1.84 uses the latest emsdk 3.1.68 [1], and it fixed an
issue with Emscripten dynamic linking and libc [2]. After that no
native-static-libs in the output if running:
```
rustc --target=wasm32-unknown-emscripten --crate-type staticlib --print native-static-libs - < /dev/null
```
[1] https://github.com/rust-lang/rust/pull/131533
[2] https://github.com/rust-lang/libc/pull/4002
|
|
a16ec8b0fb6d7035b669a13edd4d97ff0c307a0b changed the threshold to 17
for Apple Clang, but it needs to be 16 instead.
Bug: https://github.com/mesonbuild/meson/issues/14440
Closes: https://github.com/mesonbuild/meson/issues/14856
|
|
|
|
|
|
|
|
rustc only needs to be a linker if there are any Rust-ABI dependencies.
Skip it whenever linking to a C-ABI dependency. This makes it possible
for Meson to pick 'rust' whenever it sees Rust sources, but not whenever
it sees Rust used by a dependency with "rust_abi: 'c'".
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
together
Rust sources are not compiled separately: generation of the .a or .so
or binary happens at the same time as compilation. There is no separate
compilation phase where the .o file is created.
In preparation for moving generate_rust_target where generate_link is now,
make the compilation phase of generate_target skip them.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
|
|
Commit eca1ac18dc1978b15b500c9f1710c05cb1ccc0ec (#14252) added support
for properly detecting the -Wno-vla-larger-than flag: a value must be
specified for its positive form (-Wvla-larger-than=N), or GCC will exit
with the error "missing argument to ‘-Walloc-size-larger-than=’".
There is a handful of other -Wno-* flags whose positive form act in the
same manner, but are not covered here:
* -Wno-alloc-size-larger-than (GCC >=7.1.0)
* -Wno-alloca-larger-than (GCC >=7.1.0)
* -Wno-frame-larger-than (GCC >=4.4.0)
* -Wno-stack-usage (GCC >=4.7.0)
Add logic to treat these in the same way.
Signed-off-by: Henrik Lehtonen <eigengrau@vm86.se>
|
|
|
|
rustdoc does not support --print, and therefore the rpath argument corresponding
to the rust installation is not passed to doctests.
Forward anything that requires --print to the RustCompiler, thus fixing
doctests with a shared library dependency.
Fixes: #14813
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Without adding .pxi` as a known header suffix, the added test will
fail with:
```
No specified compiler can handle file stuff.pxi
```
Technically only .pxd are header files, and .pxi are "include files"
which are literally included in .pyx files. Adding them as headers
seems to be fine though, since they're kinda similar and the point is
to avoid treating them as source files.
|
|
As an initial implementation, simply adding "-C prefer-dynamic" works
for binary crates (as well as dylib and proc-macro that already used it).
In the future this could be extended to other crate types. For more
information see the comment in the changed file, as well as
https://github.com/mesonbuild/meson/issues/8828 and
https://github.com/mesonbuild/meson/issues/14215.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
RustCompiler.build_rpath_args works by appending the directory to the
arguments computed by self.linker.build_rpath_args. This does not
work if there is no argument to begin with, which happens for example
in program crates.
Use the new extra_paths argument to force inclusion of the libdir into
the rpath of the binary, even in that case.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
CUDA 12.9.0 ships a cccl that supports the new debug macros.
|
|
That is where env_opts are stored, so make the compiler call back directly
into the environment.
Suggested-by: Dylan Baker <dylan@pnwbakers.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This restores the behavior before 1.8's option store refactoring.
The bug arises because c_link_args has been stored in pending_options,
and therefore the extended value (which get_global_options correctly
computes) is overwritten by the value passed on the command line.
In fact, this bug is the reason why I added the "link_args_from_envvar"
check: the CFLAGS would be ignored anyway, so I put that logic in code
instead of relying on the option store's behavior.
The fix is to extend the value *after* the option has been added and
the pending_options resolved. This requires a tiny refactoring of
the split between CoreData.add_lang_args and compilers.get_global_options.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Commit 2d1c67f09 ("options: restore special behavior of CFLAGS vs. c_args",
2025-05-15) incorrectly checked the presence of c_link_args, and did not
apply CFLAGS if c_link_args was set. This was not the behavior of 1.7,
so remove the check.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
In get_option_std_args for the Intel C compiler, the requested command line flag is 'winlibs' which returns a list of strings of libs.
It should be 'std' as in other adjacent classes, to return the particular value of the C standard desired.
|