[BUG] relocation R_ARM_REL32 cannot be used against symbol 'OPENSSL_armcap_P' about ndk HOT 5 CLOSED

It seems to be an upstream issue. It looks to me like it should only affect the latest 3.X version.

Ah, and that'd explain why we don't see it in ndkports. We're still on the 1.1.1 series there.

My teammate suggested I build OpenSSL myself (with the patch ofc). I've been trying to do it since yesterday without much success. This seems to be the only way to tell cargo (and the dependent openssl-sys crate) to consume a different version of OpenSSL.

https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html might interest you if you haven't already found that. Makes managing that kind of local hack much easier.

Building doesn't seem to be an issue, my library also compiles and generates the static library just fine. It's only when packaging an APK that it fails.

The error is without a doubt coming from linking, which is part of the build. Static libraries are never linked though. The problem is when the static library is consumed by the shared library in your app, which is when linking happens.

Is there any way we can pay you back with some sponsoring/coffee money @DanAlbert ?

I'll be sure my boss sees that and we'll call it even :)

from ndk.

Note the -fPIC flag

-fPIC changes asm generation, but it looks like the invalid relocation is coming from hand written asm, which won't be affected by that flag. Hand written asm needs to be rewritten to be PIC.

Doesn't make a ton of sense to me why this wouldn't be a problem for everyone though.

Checks the openssl thread

Oh, I guess it is? Why aren't we seeing it then? https://android.googlesource.com/platform/tools/ndkports/+/refs/heads/main is our build of openssl and it doesn't have this problem, nor does it appear to have any obvious workarounds to avoid it. It's not using a current NDK, nor a current openssl (we haven't really had the time for that project, sadly), so that could be the problem, but otherwise you might want to look there to figure out what it's doing differently from cargo.

I'm not terribly familiar with this part of linker behavior so I can't say whether the openssl fix is right or not, but since boringssl used the same fix (and the commit message seems to say it was contributed from arm), and the openssl thread sounds like they agree it's the right fix (though done in an unmaintainable way, which appears to be why it hasn't merged), so it sounds like you may just need to apply that patch yourself or wait for openssl to merge and ship it.

@pirama-arumuga-nainar in case he has better ideas.

When I launch my application via Android Studio it works without issues. However, when I try to generate an APK via command line, I get the following error when android tries to generate an armv7 executable:

Presumably Android Studio only built for arm64 or x86_64 to match your device/emulator, and the command line also build arm32? Otherwise I'm curious what command you used to build from the command line, because that doesn't make any sense.

from ndk.

I tried upgrading ndkports to r26b and openssl 1.1.1w and it still builds fine, btw. It didn't need any changes other than raising the minSdkVersion to 21 (because r26 doesn't support 19 any more). I guess look at that and try to figure out what's different on your end.

from ndk.

Thank you very much for taking a look into this! I agree with everything you said.

• It seems to be an upstream issue. It looks to me like it should only affect the latest 3.X version.
• Unfortunately, I'm not a cargo/rust expert so is hard for me to figure out what could be failing. I tried downgrading the dependency in the hopes it would pick up a different version but doesn't seem to be working so far.
• My teammate suggested I build OpenSSL myself (with the patch ofc). I've been trying to do it since yesterday without much success. This seems to be the only way to tell cargo (and the dependent openssl-sys crate) to consume a different version of OpenSSL.
• Indeed, Android Studio seems to have built only the armv8 arch and that's why it successfully launched the app when I first tried it. I'm building a React Native app, so when I try the CLI command to generate an APK, it's when it tries to package/link armv7a.
• Building doesn't seem to be an issue, my library also compiles and generates the static library just fine. It's only when packaging an APK that it fails.

I just managed to compile 1.1.1w for the different archs as well, I will try to link it in my Rust compilation step. I'll post the results.

from ndk.

I managed to get the android app linked and running. As stated I had to compile OpenSSL manually while applying the patch in the issue:

	./Configure $ARCHITECTURE no-asm no-shared -D__ANDROID_API__=21

	make clean
	# Apply patch that fixes the armcap instruction
	# sed -e '/[.]hidden.*OPENSSL_armcap_P/d; /[.]extern.*OPENSSL_armcap_P/ {p; s/extern/hidden/ }' -i -- crypto/*arm*pl crypto/*/asm/*arm*pl
	sed -E -i '' -e '/[.]hidden.*OPENSSL_armcap_P/d' -e '/[.]extern.*OPENSSL_armcap_P/ {p; s/extern/hidden/; }' crypto/*arm*pl crypto/*/asm/*arm*pl
	make

I'm going to close this since it is not an issue with the NDK itself. Although an update to the ndkport would be good. Is there any way we can pay you back with some sponsoring/coffee money @DanAlbert ?

from ndk.