Closed ian-h-chamberlain closed 11 months ago
The RUSTFLAGS
invocation is there to link libctru
against std
I believe, there may be a problem with link order.
Yeah, you can test without it, but since std is linked near the end and introduces new symbol usages, those symbols need to get filled in by libctru again. The linker by default goes through its arguments linearly and throws away symbols that aren't needed at each stage.
I just saw this too, which may help some things: https://github.com/rust-lang/rust/issues/47384#issuecomment-1034679183
Possibly unrelated to this issue, but more useful for stuff like linker fix.
Reopened as of #40. Seems like network related functions still won't link without using RUSTFLAGS
.
I ran into a problem with this today, when linking ctrud
via the build script from ctru-sys
(but cargo-3ds
still passes an explicit -lctru
while building std
), resulting in duplicate definitions between libctrud
and libctru
at link time.
I think part of the problem here is that -Zbuild-std
builds the standard library with "plain" RUSTFLAGS
, but Cargo might end up passing different flags to ctru-sys
when it builds it (based on --release
, [profile."*"]
etc), resulting in different link flags between std
and the final executable build.
From doing a bit of searching, perhaps we can somehow use the --as-needed
flag https://github.com/rust-lang/rust/issues/99424 ? (i.e. something like RUSTFLAGS="-Clink-arg=-Wl,--as-needed"
). A little bit of testing hasn't gotten me far with it, but maybe there's some way to use it to solve this...
I am not sure of a general way to unify the linker flags (specifically -lctru[d]
) between build-std
and the downstream libraries, unless there is some magic rustc
/cargo
flag to say --link-but-only-if-nothing-else-did=ctru
. Maybe something like https://doc.rust-lang.org/cargo/reference/unstable.html#profile-rustflags-option ?
Thus far I haven't found a relevant issue in https://github.com/rust-lang/wg-cargo-std-aware/ but that repo is rather large in scope so :shrug:
If none of the above flags produce what we need, it's possible we could try to parse the cargo
flags and figure out whether we should link ctrud
or ctru
(similar to https://github.com/rust3ds/ctru-rs/blob/a636722b4978d36531e5c9e2a866cdec3387877e/ctru-sys/build.rs#L27-L33 except we'd have to figure out the PROFILE
based on the command invocation :sob:) but this doesn't seem ideal.
I think there's something to this stemming from the fact that
cargo-3ds
adds RUSTFLAGS for linking libctru, andctru-rs
also does in its build script. I'll open an issue to investigate oncargo-3ds
Originally posted by @ian-h-chamberlain in https://github.com/Meziu/ctru-rs/pull/46#issuecomment-1034901000
More context: RUSTFLAGS get updated here in
cargo-3ds
, but there is already a build script forctru-sys
which specifies that it links againstlibctru
(as well as thelinks
field in Cargo.toml, although that seems to be more about convention and less functional).If rustc will automatically link to the right libraries via the build script, is it necessary to provide via RUSTFLAGS the same linker args? I have noticed when linking fails there seem to be several duplicated references to
ctru
, e.g. (edited for clarity):I think it's probably harmless to have
-lctru
multiple times like that, but I wonder if we are doing extra work unnecessarily for the linker invocation. If so, the fix would probably be to simply remove theRUSTFLAGS
modification fromcargo-3ds
.