Is it necessary to modify `RUSTFLAGS` in `cargo-3ds`?
ian-h-chamberlain opened this issue · comments
libctru is included twice
I think there's something to this stemming from the fact that cargo-3ds adds RUSTFLAGS for linking libctru, and ctru-rs also does in its build script. I'll open an issue to investigate on cargo-3ds
Originally posted by @ian-h-chamberlain in rust3ds/ctru-rs#46 (comment)
More context: RUSTFLAGS get updated here in cargo-3ds, but there is already a build script for ctru-sys which specifies that it links against libctru (as well as the links 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):
error: linking with `arm-none-eabi-gcc` failed: exit status: 1
|
= note: "arm-none-eabi-gcc"
"-specs=3dsx.specs"
"-mtune=mpcore"
"-mfloat-abi=hard"
"-mtp=soft"
... lots of object files ...
"-Wl,--as-needed"
"-L"
"/Users/ianchamberlain/Documents/Development/3ds/ctru-rs/target/armv6k-nintendo-3ds/debug/deps"
"-L"
"/Users/ianchamberlain/Documents/Development/3ds/ctru-rs/target/debug/deps"
"-L"
"/opt/devkitpro/libctru/lib"
"-L"
"/opt/devkitpro/libctru/lib"
"-L"
"/Users/ianchamberlain/.rustup/toolchains/horizon/lib/rustlib/armv6k-nintendo-3ds/lib"
"-lctru"
"-Wl,-Bstatic"
... rlib files ...
"-Wl,-Bdynamic"
"-lctru"
"-lctru"
"-lc"
"-lm"
"-lctru"
"-lc"
"-lm"
"-lctru"
"-Wl,--eh-frame-hdr"
"-Wl,-znoexecstack"
"-L"
"/Users/ianchamberlain/.rustup/toolchains/horizon/lib/rustlib/armv6k-nintendo-3ds/lib"
"-o"
"/Users/ianchamberlain/Documents/Development/3ds/ctru-rs/target/armv6k-nintendo-3ds/debug/deps/common-238f93ba962b2c97.elf"
"-Wl,--gc-sections"
"-no-pie"
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 the RUSTFLAGS modification from cargo-3ds.
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: rust-lang/rust#47384 (comment)
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 rust-lang/rust#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 🤷
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 😭) but this doesn't seem ideal.