GNOME Bugzilla – Bug 794599
Conflicting symbols from OpenSSL and something else preventing static linking: sha1_block_data_order
Last modified: 2018-04-23 07:08:21 UTC
We're trying to build an android app with gstreamer 13.91 or 14.0, both are not working no matter which NDK Version we use, nor what OS (Ubuntu,OSX). There is always the same error: /home/{name}/Android/Sdk/ndk-bundle/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/aarch64-linux-android/bin/ld.gold Error:error: /home/{name}/Documents/gstream/gstreamer-1.0-android-universal-1.13.91/arm64/lib/libcrypto.a(sha1-armv8.o): multiple definition of 'sha1_block_data_order' Error:linker command failed with exit code 1 (use -v to see invocation)
This is likely because of this upstream bug: https://bugs.chromium.org/p/chromium/issues/detail?id=448386 boringssl is exporting its symbols in the global namespace. We should work around this in our build.
Ok so there's no duplicated symbol from our side but instead Android is leaking symbols that conflict with ours. Nothing much we can do here then other than requiring a fixed NDK.
Hrm? My armv8 build has that conflict between openssl and gnutls: .../cerbero/dist/android_universal/arm64/lib/libcrypto.a(sha1-armv8.o): multiple definition of 'sha1_block_data_order' .../aarch64-linux-android/bin/ld.gold: /home/matt/Projects/cerbero/build/dist/android_universal/arm64/lib/libgnutls.a(sha1-armv8.o): previous definition here It doesn't seem to occur with armv7 for some reason though.
Ok, so this was not actually the Chromium bug where Android itself exported those symbols. In that case we should just rename the symbols. They don't seem to be part of the public API.
commit 869c208e25140c308e84be51a6ada1dd84014a78 Author: Matthew Waters <matthew@centricular.com> Date: Thu Mar 29 22:59:20 2018 +1100 gnutls: rename private symbols for armv8, x86 to not conflict with openssl Modifying gnutls was chosen because for other architectures, the names are already slightly different and don't conflict with openssl whereas openssl's symbol names are all the same regardless of architecture. gnutls also only has 2 accelarated architectures to change compared to openssl's 5+. And couple of follow up commits for other platforms. commit ca687e9ca4a2a0aab744d460d552ef4806ec54a4 Author: Matthew Waters <matthew@centricular.com> Date: Wed Apr 11 15:04:59 2018 +1000 recipes/gnutls: also rename assembly functions on macos/ios Fixes build error: Undefined symbols for architecture x86_64: "__aesni_cbc_encrypt", referenced from: _aes_encrypt in libaccelerated.a(aes-cbc-x86-aesni.o) _aes_decrypt in libaccelerated.a(aes-cbc-x86-aesni.o) "__aesni_ctr32_encrypt_blocks", referenced from: _aes_gcm_encrypt in libaccelerated.a(aes-gcm-x86-pclmul-avx.o) _aes_gcm_decrypt in libaccelerated.a(aes-gcm-x86-pclmul-avx.o) _aes_gcm_encrypt in libaccelerated.a(aes-gcm-x86-pclmul.o) _aes_gcm_decrypt in libaccelerated.a(aes-gcm-x86-pclmul.o) "__aesni_ecb_encrypt", referenced from: _x86_aes_encrypt in libaccelerated.a(aes-ccm-x86-aesni.o) _x86_aes_encrypt in libaccelerated.a(aes-gcm-x86-aesni.o) _aes_gcm_cipher_setkey in libaccelerated.a(aes-gcm-x86-pclmul-avx.o) _aes_gcm_setiv in libaccelerated.a(aes-gcm-x86-pclmul-avx.o) _aes_gcm_cipher_setkey in libaccelerated.a(aes-gcm-x86-pclmul.o) _aes_gcm_setiv in libaccelerated.a(aes-gcm-x86-pclmul.o) "__aesni_set_decrypt_key", referenced from: _aes_cipher_setkey in libaccelerated.a(aes-cbc-x86-aesni.o) "__aesni_set_encrypt_key", referenced from: _aes_cipher_setkey in libaccelerated.a(aes-cbc-x86-aesni.o) _aes_ccm_cipher_setkey in libaccelerated.a(aes-ccm-x86-aesni.o) _aes_gcm_cipher_setkey in libaccelerated.a(aes-gcm-x86-aesni.o) _aes_gcm_cipher_setkey in libaccelerated.a(aes-gcm-x86-pclmul-avx.o) _aes_gcm_cipher_setkey in libaccelerated.a(aes-gcm-x86-pclmul.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) commit 6fd9d2e6899c20b71f54ba68a2257af33b381128 Author: Matthew Waters <matthew@centricular.com> Date: Mon Apr 9 19:22:29 2018 +1000 gnutls: fix assembly symbol names for windows x86
*** Bug 795455 has been marked as a duplicate of this bug. ***
*** Bug 795454 has been marked as a duplicate of this bug. ***