Android linking fails with NDK r11b: undefined reference to 'bsd_signal'

[skligys]

Cross-compiling on Linux x64 to Android, rustc compiled from nightly sources as of 2016-03-17.

$ rustc --version -v
rustc 1.9.0-dev
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-unknown-linux-gnu
release: 1.9.0-dev

$ cat - >hello.rs
fn main() {
println!("Hello, rusty Android!");
}
^D

$ rustc --target=arm-linux-androideabi -C linker=$HOME/Work/Android/NdkStandalone/bin/arm-linux-androideabi-gcc -C link-args="-pie -fPIE" hello.rs
error: linking with /home/skirmantas/Work/Android/NdkStandalone/bin/arm-linux-androideabi-gcc failed: exit code: 1
note: "/home/skirmantas/Work/Android/NdkStandalone/bin/arm-linux-androideabi-gcc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-Wl,--allow-multiple-definition" "-L" "/usr/local/stow/rustc-20160317/lib/rustlib/arm-linux-androideabi/lib" "hello.0.o" "-o" "hello" "-Wl,--gc-sections" "-pie" "-nodefaultlibs" "-L" "/usr/local/stow/rustc-20160317/lib/rustlib/arm-linux-androideabi/lib" "-Wl,-Bstatic" "-Wl,-Bdynamic" "/usr/local/stow/rustc-20160317/lib/rustlib/arm-linux-androideabi/lib/libstd-9026086f.rlib" "/usr/local/stow/rustc-20160317/lib/rustlib/arm-linux-androideabi/lib/libcollections-9026086f.rlib" "/usr/local/stow/rustc-20160317/lib/rustlib/arm-linux-androideabi/lib/librustc_unicode-9026086f.rlib" "/usr/local/stow/rustc-20160317/lib/rustlib/arm-linux-androideabi/lib/librand-9026086f.rlib" "/usr/local/stow/rustc-20160317/lib/rustlib/arm-linux-androideabi/lib/liballoc-9026086f.rlib" "/usr/local/stow/rustc-20160317/lib/rustlib/arm-linux-androideabi/lib/liballoc_jemalloc-9026086f.rlib" "/usr/local/stow/rustc-20160317/lib/rustlib/arm-linux-androideabi/lib/liblibc-9026086f.rlib" "/usr/local/stow/rustc-20160317/lib/rustlib/arm-linux-androideabi/lib/libcore-9026086f.rlib" "-l" "dl" "-l" "log" "-l" "gcc" "-l" "gcc" "-l" "c" "-l" "m" "-pie" "-fPIE" "-l" "compiler-rt"
note: /usr/local/stow/rustc-20160317/lib/rustlib/arm-linux-androideabi/lib/libstd-9026086f.rlib(std-9026086f.0.o):std.0.rs:function rt::lang_start::h1deaaba938bd63a9Xqz: error: undefined reference to 'bsd_signal'
collect2: error: ld returned 1 exit status

error: aborting due to previous error

[alexcrichton]

Hm this may be a backwards incompatible change made in the NDK? I believe super old versions had the function called bsd_signal and then it changed recently to signal and now the bsd_signal function has been removed?

[skligys]

Thanks for taking a look.

Indeed, the arch-arm/usr/include/signal.h header up to "android-19" contained:

/* differentiater between sysv and bsd behaviour 8*/
extern __sighandler_t sysv_signal(int, __sighandler_t);
extern __sighandler_t bsd_signal(int, __sighandler_t);

/* the default is bsd */
static __inline__ __sighandler_t signal(int s, __sighandler_t f)
{
    return bsd_signal(s,f);
}

but starting at "android-21" (there is no android-20) has just:

extern sighandler_t signal(int, sighandler_t);

So it looks that stdlib would have to use different symbols depending on which version of Android SDK it was targeting.

[Nercury]

How are we going to solve BC compatibility? Can we link to different names depending on android ndk version?

I have tried rebuilding rust std library with this change in libc and I can link my little android lib successfully.

[alexcrichton]

Yeah this is an interesting question for us. It seems like right now we can't span multiple android versions. Currently the oldest version supported is API level 18, but we could mitigate this in a few ways:

1. Bump the minimum API level. Note that we have requests to move this back as well.
2. Avoid usage of signal in the standard library (may produce inconsistent results).
3. Look up the signal symbol at runtime rather than link to it.

I'd probably lean towards option 3 for now and modifying the standard library as it seems the most flexible?

[alexcrichton]

Oh another options is for consumers of libc to have a choice, we could do NDK version detection like @Nercury mentioned via something like:

• A build script could detect the version of the Android compiler and tweak the API appropriately
• Features could be used on libc to indicate what level of android compatibility is desired
• We could bake the API level of the Android NDK into the target triple, for example arm-linux-androideabi18 or something like that.

I'd personally rather avoid these options for now, but may as well consider everything!

Also cc @rust-lang/tools, interesting API compatibility story here.

[Nercury]

Some thoughts:

The least painful option for users would be to do the symbol lookup at runtime, however I fear that moving such solutions to runtime would require us to debug any issues at runtime too.

Baking android tools version to arm-linux-androideabi18 might be an issue, because of the number of triplets that are going to appear (if we wish to add more build targets for android, like arm7-hf, arm64, x64, etc).

If we use features like android-18, android-19, we may keep the latest one as the "default". The only issue I see here that other platforms do not need to care about android platform and these flags may get a bit messy.

If we don't want to have a separate std lib for different android versions, it looks like the smoothest solution is indeed to do the symbol lookup at runtime. And do that only on Android platform.

[alexcrichton]

cc rust-lang/rust#32415, a patch for the standard library