Static linking fails because of symbol duplication #40
Labels
Comments
|
Also note that linking against libstrophe.a statically, but libcrypto dynamically seems to succeed at link time, but at runtime crashes when trying to initialize TLS (at least on systems where OpenSSL is compiled with -fstack-protector). Took a while to track it down to the internal SHA1 functions; putting the #defines back to rename them fixes the issue. |
msantos
added a commit
to msantos/libstrophe
that referenced
this issue
May 24, 2015
Fix statically linking against libstrophe by renaming the internal SHA functions: strophe#40 Although the same function names are used by libstrophe and OpenSSL, the signatures and contexts of the SHA functions differ, resulting in a segfault if the OpenSSL versions are substituted.
Closed
woodsts
pushed a commit
to woodsts/buildroot
that referenced
this issue
Sep 28, 2015
libstrophe.a and libcrypto.a have symbols with equal names, so executables can't be statically linked with libstrophe and openssl: sha1dgst.c:(.text+0x1b4c): multiple definition of `SHA1_Update' sha1dgst.c:(.text+0x1cc0): multiple definition of `SHA1_Final' sha1dgst.c:(.text+0x1e78): multiple definition of `SHA1_Init Renaming the internal SHA functions fixes the problem. Issue reported upstream: strophe/libstrophe#40 Fixes: http://autobuild.buildroot.net/results/047/047e319b9d7bf0cdaabc007326a6d67de2c1ee52/ Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
Fixed in master. I've added prefix crypto_ to SHA1 API. In the future all crypto API can be grouped and moved to crypto/ subdirectory. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
libstrophe.a and libcrypto.a have symbols with equal names, so executables can't be statically linked with libstrophe and openssl.
The text was updated successfully, but these errors were encountered: