rust3ds / cargo-3ds

Cargo command to work with Nintendo 3DS project binaries.
Apache License 2.0
59 stars 10 forks source link

Is it necessary to modify `RUSTFLAGS` in `cargo-3ds`? #14

Closed ian-h-chamberlain closed 11 months ago

ian-h-chamberlain commented 2 years ago

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 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 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.

Meziu commented 2 years ago

The RUSTFLAGS invocation is there to link libctru against std I believe, there may be a problem with link order.

AzureMarker commented 2 years ago

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.

AzureMarker commented 2 years ago

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.

Meziu commented 1 year ago

Reopened as of #40. Seems like network related functions still won't link without using RUSTFLAGS.

ian-h-chamberlain commented 1 year ago

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.