aee941559 ("rust: recursively pull proc-macro dependencies as well")
had to be reverted (in a66cb97e8) because it broke Mesa cross
compilation. This happened because a C shared library was linked with
a Rust C-ABI static library, which caused it to inherit the proc macro
dependency the Rust static library was linked with.
The right way to handle this is for only Rust targets to inherit proc
macro dependencies from static libraries they link with. A Rust
executable, library, or whatever will need the proc macros its Rust
dependencies use, as illustrated in the test case that I've
reintroduced here.
I've verified that Mesa still cross compiles correctly with this
change. The same failure was also identified by the "rust/21
transitive dependencies" test case, but only when cross compiling, so
it wasn't caught by CI.
Co-authored-by: Xavier Claessens <xavier.claessens@collabora.com>
Cargo.lock is essentially identical to subprojects/*.wrap files. When a
(sub)project has a Cargo.lock file this allows automatic fallback for
its cargo dependencies.
This reverts commit aee941559c.
The commit being reverted breaks compilation of a major Meson consumer
(Mesa). As a result, various distros are either pinning to <1.4.0 (before
the commit) or performing this same revert downstream.
Fixing a regression takes priority, so let's revert.
Fixes: https://github.com/mesonbuild/meson/issues/12973
We have two copies of other.h, one of which is generated. If we don't
include the include/ directory then building fails unless the
custom_target which copies it over, happens to run early enough. On
parallel builds this may fall on its face.
When linking with a Rust rlib, we should also link with its external
system dependencies. This was currently done only for C ABI crates, do
it for both rlib and staticlib now.
When the proc-macro rlib is in a different subdir, it would miss the
needed -L argument and rustc would not find it. Meson was assuming that
proc-macros are only needed when building libraries that uses it, but it
turns out that was wrong, as show by the unit test.
Cargo implements this configuration option to override the entry point
of the library.
To get test coverage, I've modified one of the two Cargo subprojects
in the test to use a non-default library entrypoint. The other still
uses the default.
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
In the case r1 -> s1 -> s2 where s1 and s2 are uninstalled C static
libraries, the libs1.a rule does not depend on libs2.a. That means that
r1 rule must depend on both s1 and s2.
Pass link arguments directly down to linker by using `-C link-args=`
instead of letting rustc/linker resolve `-l` arguments. This solves
problems with e.g. +verbatim not being portable. Note that we also pass
`-l` args as `-Clink-args=-l` because rustc would otherwise reorder
arguments and put `-lstdc++` before `-Clink-args=libfoo++.a`.
However, when building a rlib/staticlib we should still use `-l`
arguments because that allows rustc to bundle static libraries we
link-whole. In that case, since there is no platform specific dynamic
linker, +verbatim works.
This also fix installed staticlib that now bundle uninstalled static
libraries it links to (recursively). This is done by putting them all
into self.link_whole_targets instead of putting their objects into
self.objects, and let rustc do the bundling. This has the extra
advantage that rustc can bundle static libries built with CustomTarget.
Disable bundling in all other cases, otherwise we could end up with
duplicated objects in static libraries, in diamond dependency graph
case.
Fixes: #12484
This does require hacking up the test pretty badly, since we need to not
ever pass GCC these invalid values. But it's preferable to writing
another project test I think.
Co-Authored-by: Nirbheek Chauhan <nirbheek@centricular.com>
This means that arguments set via `add_global_arguments`,
`add_project_arguments` and by either the `-Dc_args` or `CFLAGS` are
applied to bindgen as well. This can be important when, among other
things, #defines are set via these mechanisms.
Fixes: #12065
When an installed static library A links to an internal static library B
built using a custom_target(), raise an error instead of a warning. This
is because to be usable, A needs to contain B which would require to
extract the archive to get its objects files.
This used to work, but was printing a warning and was installing a
broken static library, because we used to overlink in many cases, and
that got fixed in Meson 1.2.0. It now fails at link time with symbols
from the custom target not being defined. It's better to turn the
warning into a hard error at configure time.
While at it, noticed this situation can happen for any internal custom
or rust target we link to, recursively.
get_internal_static_libraries_recurse() could be called on CustomTarget
objects which do not implement it, and even if we did not call that
method, it would still fail when trying to call extract_all_objects() on
it.
Fixes: #12006
These result in very large binaries when linked, and are not generally
useful. A user can turn them back on by passing `-C overflow-checks=yes`
manually via `-Drust_args` or the `RUSTFLAGS` environment variable
fixes: #11785
Rust by default links with the default MSVCRT, (dynamic, release).
MSVCRT's cannot be mixed, so if Meson compiles a C or C++ library and
links it with the debug MSVCRT, then tries to link that with the Rust
library there will be failures. There is no built-in way to fix this for
rustc, so as a workaround we inject the correct arguments early in the
linker line (before any libs at least) to change the runtime. This seems
to work and is recommended as workaround in the upstream rust bug
report: https://github.com/rust-lang/rust/issues/39016.
Given that this bug report has been opened since 2017, it seems unlikely
to be fixed anytime soon, and affects all (currently) released versions
of Rust.
I noticed when building a project that uses a proc macro that Meson
passed -C prefer-dynamic for the executable, and not the proc macro,
while cargo passed -C prefer-dynamic for the proc macro, but not for
the executable. Meson's behavior broke setting -C panic=abort on the
executable.
As far as we can tell, because we explicitly pass each library path to
rustc, the only thing -C prefer-dynamic affects in Meson is how the
standard libraries are linked. Generally, one does not want the
standard libraries to be dynamically linked, because if the Rust
compiler is ever updated, anything linked against the old standard
libraries will likely break, due to the lack of a stable Rust ABI.
Therefore, I've reorganised Meson's behavior around the principle that
the standard libraries should only be dynamically linked when Rust
dynamic linking has already been opted into in some other way. The
details of how this manifests are now explained in the documentation.
This allows changing the crate name with which a library ends up being
available inside the Rust code, similar to cargo's dependency renaming
feature or `extern crate foo as bar` inside Rust code.
Rust has a `debug_assert!()` macro, which is designed to be toggled on
the command line. It is on by default in debug builds, and off by
default in release builds, in cargo. This matches what meson's b_ndebug
option does in `if-release` mode.
Rust doesn't have a concept of dependency compile arguments, i.e.
something like headers. Dependencies are linked in and all required
metadata is provided by the linker flags.
During evaluation of codeblocks, we start off with an iteration of
nodes, and then while evaluating them we may update the global
self.current_node context. When catching and formatting errors, we
didn't take into account that the node might be updated from the
original top-level iteration.
Switch to formatting errors using self.current_node instead, to ensure
we can point at the likely most-accurate actual cause of an error.
Also update the current node in a few more places, so that function
calls always see the function call as the current node, even if the most
recently parsed node was an argument to the function call.
Fixes#11643
Allows getting closer to `./run_project_tests.py -- -Dwerror=true`.
- when argc and argv are not *both* used, there's a standard, compliant
mechanism to mark the variable as unused
- generated code should not build as -Werror
- more thoroughly comment out some commented code
spaette
Alyssa Ross
Dylan Baker
Jussi Pakkanen
Xavier Claessens
Sam James
Eli Schwartz
Karol Herbst
Sebastian Dröge
Volker Weißmann
Josh Soref
Eli Schwartz