Provide libgcc linker script workaround for NDK >= 23

[rib]

libgcc was removed from NDK v23 which breaks Rust builds against pre-built standard libraries that were linked against libgcc instead of libunwind.

As a workaround this ensures that there is a libgcc.a in the library search paths which is a linker script that will redirect to link with libunwind instead.

The libgcc.a linker script is created under:
target/cargo-ndk/libgcc_workaround/libgcc.a

Fixes: #22

For reference the underlying issue has been fixed upstream but it still depends on building the std library from source (via -Zbuild-std) instead of using the pre-built libraries distributed via rustup. This currently means using a nightly toolchain. See: rust-lang/rust#85806

[MarijnS95]

You might want to look at how we implemented and evolved this workaround in ndk-build instead.

[rib]

er, okey? I mean fwiw I did skim it before I opened this PR and it vaguely looked similar - not sure what the frowny face is about here - I guess I've stepped on a nerve? maybe you could say what's wrong with this?

[rib]

For reference this is the code in ndk-build:

// Workaround for https://github.com/rust-windowing/android-ndk-rs/issues/149:
    // Rust (1.56 as of writing) still requires libgcc during linking, but this does
    // not ship with the NDK anymore since NDK r23 beta 3.
    // See https://github.com/rust-lang/rust/pull/85806 for a discussion on why libgcc
    // is still required even after replacing it with libunwind in the source.
    // XXX: Add an upper-bound on the Rust version whenever this is not necessary anymore.
    if ndk.build_tag() > 7272597 {
        let cargo_apk_link_dir = target_dir
            .as_ref()
            .join("cargo-apk-temp-extra-link-libraries");
        std::fs::create_dir_all(&cargo_apk_link_dir)
            .map_err(|e| NdkError::IoPathError(cargo_apk_link_dir.clone(), e))?;
        let libgcc = cargo_apk_link_dir.join("libgcc.a");
        std::fs::write(&libgcc, "INPUT(-lunwind)").map_err(|e| NdkError::IoPathError(libgcc, e))?;

        // cdylibs in transitive dependencies still get built and also need this
        // workaround linker flag, yet arguments passed to `cargo rustc` are only
        // forwarded to the final compiler invocation rendering our workaround ineffective.
        // The cargo page documenting this discrepancy (https://doc.rust-lang.org/cargo/commands/cargo-rustc.html)
        // suggests to resort to RUSTFLAGS.
        // Note that `rustflags` will never be empty because of an unconditional `.push_str` above,
        // so we can safely start with appending \x1f here.
        rustflags.push_str("\x1f-L\x1f");
        rustflags.push_str(
            cargo_apk_link_dir
                .to_str()
                .expect("Target dir must be valid UTF-8"),
        );
    }

    cargo.env("CARGO_ENCODED_RUSTFLAGS", rustflags);

Although I wrote the patch before going to check this, I did actually already check this out of curiosity and it looks pretty similar to what my PR does?

There are more comments here about RUSTFLAGS I guess because some other solution didn't work out and I suppose it's just dumb luck that I went with passing the -L flag with RUSTFLAGS.

It would probably be good to use CARGO_ENCODED_RUSTFLAGS considering the possibility of target directory paths with spaces - maybe that's what you were thinking of?

[rib]

Okey, the updated PR now:

• uses CARGO_ENCODED_RUSTFLAGS and I tested that it works if the target directory has spaces
• reads any pre-set CARGO_ENCODED_RUSTFLAGS value from the environment so that the workaround doesn't discard any user-set flags
• creates a directory named libgcc-workaround instead of libgcc_workaround
• has more comments

[MarijnS95]

s/RUSTFLAGS/CARGO_ENCODED_RUSTFLAGS?

[MarijnS95]

If you're copying things from ndk-build anyway, why not use the same r23 beta3 tag: https://github.com/rust-windowing/android-ndk-rs/blob/814be0864bd05f6fff616299ce25c075487fa244/ndk-build/src/cargo.rs#L54

[rib]

yeah, I considered it but it didn't look like cargo-ndk parsed the build tag in the same way.

Since it doesn't look like you can download the first two betas anymore and also since by their very nature beta releases shouldn't be relied on it seems reasonable in this case to just check the major number.

[MarijnS95]

er, okey? I mean fwiw I did skim it before I opened this PR and it vaguely looked similar - not sure what the frowny face is about here - I guess I've stepped on a nerve?

The official term is the :confused: emoji, which is how I felt when reading your change.

maybe you could say what's wrong with this?

Looks like you found some yourself, though I wouldn't have bothered for the s/_/- change nor the comments. At the same time you could've used the build tag to distinguish r23 beta2 and beta3 accordingly.

---

Regardless my point still stands; this crate should use (or merge with) ndk-build instead of reinventing copy-pasting the wheel to fix identical issues up to a year later. But alas, I don't use it (cargo-apk does the same job when executed correctly) so such a change won't come out of my time budget.