Fixing dynamic linker errors when using libc with openssl - c

Here's a simple hello world sha1-hasher that's using the openssl library.
#include <openssl/sha.h>
#include <stdio.h>
#include <stdlib.h>
int main()
{
system("printf '%s' 'hello world' | sha1sum");
unsigned char digest[SHA_DIGEST_LENGTH];
char digest_pr[(SHA_DIGEST_LENGTH)*2+1];
SHA_CTX ctx;
if(!SHA1_Init(&ctx)) return 1;
#define STR_STRLEN(A) A, (sizeof(A)/sizeof(*(A))-1)
if(!SHA1_Update(&ctx,STR_STRLEN("hello"))) return EXIT_FAILURE;
if(!SHA1_Update(&ctx,STR_STRLEN(" world"))) return EXIT_FAILURE;
if(!SHA1_Final(digest,&ctx)) return EXIT_FAILURE;
#define DIGITS "0123456789abcdef"
for(size_t i=0;i<sizeof(digest);i++){
digest_pr[i*2+0]=DIGITS[digest[i]/16];
digest_pr[i*2+1]=DIGITS[digest[i]%16];
}
digest_pr[(SHA_DIGEST_LENGTH)*2]='\0';
puts(digest_pr);
}
On a Mint/Ubuntu with libssl-dev installed, I can compile and link it with $CC sha.c (where CC is one of gcc, tcc, or clang) and then successfully run it, but this didn't work with musl so I grabbed the openssl source (git clone https://github.com/openssl/openssl), configured it with ./config --prefix=/usr/local/musl, built it and installed it and now musl-gcc sha.c -lcrypto works but running LD_LIBRARY_PATH=/usr/local/musl/lib a.out gets me:
Error relocating /usr/local/musl/lib/libcrypto.so.1.1: __fprintf_chk: symbol not found
Error relocating /usr/local/musl/lib/libcrypto.so.1.1: makecontext: symbol not found
Error relocating /usr/local/musl/lib/libcrypto.so.1.1: setcontext: symbol not found
Error relocating /usr/local/musl/lib/libcrypto.so.1.1: __register_atfork: symbol not found
Error relocating /usr/local/musl/lib/libcrypto.so.1.1: __memcpy_chk: symbol not found
Error relocating /usr/local/musl/lib/libcrypto.so.1.1: __strcat_chk: symbol not found
Error relocating /usr/local/musl/lib/libcrypto.so.1.1: secure_getenv: symbol not found
Error relocating /usr/local/musl/lib/libcrypto.so.1.1: __vfprintf_chk: symbol not found
Error relocating /usr/local/musl/lib/libcrypto.so.1.1: __syslog_chk: symbol not found
Error relocating /usr/local/musl/lib/libcrypto.so.1.1: __memset_chk: symbol not found
Error relocating /usr/local/musl/lib/libcrypto.so.1.1: __fread_chk: symbol not found
Error relocating /usr/local/musl/lib/libcrypto.so.1.1: getcontext: symbol not found
Error relocating /usr/local/musl/lib/libcrypto.so.1.1: __sprintf_chk: symbol not found
What's causing this and how can I fix it?

It seems that your OpenSSL is not built against musl-libc.
The musl-libc has its own dynamic linker (see https://wiki.musl-libc.org/faq.html), we could create a soft link for the musl dynamic linker. (-syslibdir is the directory in which the dynamic library, e.g. ld-musl-x86_64.so.1, is, see https://wiki.musl-libc.org/getting-started.html)
sudo ln -sf <YOUR-MUSL-LIBC-syslibdir/ld-musl-x86_64.so.1> /usr/bin/musl-ldd
Then you could see whether openssl is built against musl-libc. When I build OpenSSL using glibc, it shows the following error
$ musl-ldd <YOUR-OPENSSL-SRC>/libcrypto.so.1.1
musl-ldd (0x7fcd5a749000)
libdl.so.2 => musl-ldd (0x7fcd5a749000)
libpthread.so.0 => musl-ldd (0x7fcd5a749000)
libc.so.6 => musl-ldd (0x7fcd5a749000)
Error relocating ./libcrypto.so.1.1: makecontext: symbol not found
Error relocating ./libcrypto.so.1.1: setcontext: symbol not found
Error relocating ./libcrypto.so.1.1: __register_atfork: symbol not found
Error relocating ./libcrypto.so.1.1: getcontext: symbol not found
And the glib dynamic linker works fine,
$ ldd <YOUR-OPENSSL-SRC>/libcrypto.so.1.1
linux-vdso.so.1 (0x00007ffd395a6000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff6e6e64000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff6e6e41000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff6e6c4f000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff6e71d7000)
To build OpenSSL using musl-libc, we have to also specify the location of linux headers to avoid errors like <linux/mman.h>
I only have attempted to build OpenSSL using Clang and Musl-libc, here is the clang wrapper I used https://gist.github.com/randoruf/d1aa4e8acb0a852addcd2b84fc003719.
(taken from https://qiita.com/kakinaguru_zo/items/399ab7ea716a56aef50c which is written by kakinaguru_zo)
But there are still a few issues in the clang-wrapper.
This wrapper will link the startfile (e.g. Scrt1.o) regardless of building libraries or executables. Apparently, only executables need startfile. Hence, if you use this wrapper, you may encounter the following strange error (main symbol not found):
$ musl-clang mylibrary.c -shared -fPIC -o libmylibrary.so
$ musl-ldd libmylibrary.so
ld-musl-x86_64.so.1 (0x7f49faef7000)
libc.so => ld-musl-x86_64.so.1 (0x7f49faef7000)
Error relocating libmylibrary.so: main: symbol not found
If the library has the startfile, it may have an entry to main. This is the reason why the main symbol is not found.
The solution is not to include startfile for shared libraries (the new clang wrapper should fix the problem).
Another issue is that test_errstr, test_ca, test_ssl_new will not pass due to the fact that the operating system and its software are built against glibc.
Details are posted on my blog https://randoruf.github.io/2022/08/23/musl-libc-ubuntu.html#about-the-test-case-in-openssl
The final issue is that this wrapper only supports c language. Another wrapper may be helpful see https://github.com/esjeon/musl-clang/blob/master/musl-clang

Related

How to compile longjmp using emcc?

I'm trying to diagnose a linker issue with emcc. I've got it down to the following file:
#include <setjmp.h>
jmp_buf error;
int main(int argc, char *argv[]) {
int n = setjmp(error);
if (n)
return n;
longjmp(error, 33);
return 0;
}
When compiled with gcc, this file produces an a.out that exits with code 33 as expected. But when compiled with emcc, it fails at the linking step, with this error:
nr#homedog ~/s/c [1]> emcc -s LLD_REPORT_UNDEFINED longjmp.c
error: undefined symbol: __invoke_void_$struct___jmp_buf_tag*_i32 (referenced by top-level compiled C/C++ code)
warning: To disable errors for undefined symbols use `-s ERROR_ON_UNDEFINED_SYMBOLS=0`
warning: ___invoke_void_$struct___jmp_buf_tag*_i32 may need to be added to EXPORTED_FUNCTIONS if it arrives from a system library
error: undefined symbol: emscripten_longjmp_jmpbuf (referenced by top-level compiled C/C++ code)
warning: _emscripten_longjmp_jmpbuf may need to be added to EXPORTED_FUNCTIONS if it arrives from a system library
Adding it to EXPORTED_FUNCTIONS results instead in this error:
wasm-ld: error: symbol exported via --export not found: emscripten_longjmp_jmpbuf
What do I need to do to compile this file?
I am running Debian stable (bullseye) with Emscripten version 2.0.12.
ETA: emcc reports versions as follows:
nr#homedog ~/s/c [1]> emcc -v
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 2.0.12
Debian clang version 11.0.1-2
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /usr/bin
It looks like you have a mismatched llvm (clang) and emscripten versions. We recommend using emsdk to install all correct dependencies (how are you install them?). If you don't want use emsdk you will need to build llvm from source at the correct revision.
Your example works find with the latest version of emscripten:
$ emcc -v
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 2.0.29-git (6e9e10d3f78eb249bf09922a23e19c3f81a86d0f)
...
$ emcc -s LLD_REPORT_UNDEFINED setjmp.c

Undefined references to libm symbols after upgrading Linux distro

I upgraded my Linux distro from Pop OS 19.10 to 20.04, and it naturally included upgrades to glibc & co. Since then, I started getting linker errors for libm symbols like __pow_finite.
Unfortunately, the code that references these symbols is a static library (libWithPowFiniteRef.a in the redacted snippet below) with third-party proprietary code. I don't have access to source.
I checked /lib/x86_64-linux-gnu/libm.so.6 using nm. The symbol is there:
nm -gD /lib/x86_64-linux-gnu/libm.so.6
...
0000000000010e00 W powf64x
00000000000471f0 i __powf_finite
000000000002ed90 i __pow_finite
0000000000010e00 W powl
0000000000019860 T __powl_finite
...
So I can't explain the errors:
g++ -o ./media_tests -Wl,--verbose -Wl,--start-group #"./media_tests.rsp" -ldl -lpthread -lrt ../../third_party/other.so ../../third_party/redacted/lib/Linux/x64/libWithPowFiniteRef.a -Wl,--end-group
...
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libm.so failed
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libm.a failed
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libm.so succeeded
...
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libm.so failed
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libm.a failed
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libm.so succeeded
opened script file /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libm.so
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libm.so
opened script file /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libm.so
attempt to open /lib/x86_64-linux-gnu/libm.so.6 succeeded
/lib/x86_64-linux-gnu/libm.so.6
...
/usr/bin/ld:../../third_party/redacted/lib/Linux/x64/redacted.a(redacted.o): in function `RedactedX':
redacted1.c:(.text+0xbb0): undefined reference to `__pow_finite'
/usr/bin/ld: ../../third_party/redacted/lib/Linux/x64/redacted.a(redacted.o): in function `RedactedY':
redacted2.c:(.text+0x7ad9): undefined reference to `__pow_finite'
/usr/bin/ld: redacted.c:(.text+0x8c74): undefined reference to `__pow_finite'
/usr/bin/ld: link errors found, deleting executable `./media_tests'
Maybe we the solution is to request a new static lib from the vendor, but I would like to understand why.

hidden symbol `stat' in libc_nonshared.a(stat.oS) is referenced by DSO

I'm trying to use methods contained in a shared library (libscplugin.so).
I have satisfied all of the libraries requirements:
libc.so with a symlink to libc.so.6
libz.so with a symlink to libz.so.1.2.8
libstdc++.so with a symlink to libstdc++.so.6.0.20
Upon compilation I get the following error message:
$ gcc test.c -o test -L/usr/lib/arm-linux-gnueabihf/ -lscplugin
/usr/bin/ld: test: hidden symbol `stat' in /usr/lib/arm-linux-gnueabihf/libc_nonshared.a(stat.oS) is referenced by DSO
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
The only reference I could find to libc_nonshared.a is in /usr/lib/arm-linux-gnueabihf/libc.so:
$ cat libc.so
/* GNU ld script
Use the shared library, but some functions are only in
the static library, so try that secondarily. */
OUTPUT_FORMAT(elf32-littlearm)
GROUP ( /lib/arm-linux-gnueabihf/libc.so.6 /usr/lib/arm-linux-gnueabihf/libc_nonshared.a AS_NEEDED ( /lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 ) )
In test.c I'm attempting to use two functions of the shared library (totally unrelated to stat). What can I do to get this to compile ?
Your problem is here:
I have satisfied all of the libraries requirements:
libc.so with a symlink to libc.so.6
That is not a valid setup for glibc. libc.so is supposed to be a text file (linker script) as you saw at the end of your answer. You're doing something weird and unnecessary if you're making symlinks to shared libraries like this yourself. Use the libc.so that's provided (and you need to do this when building your other shared libraries -- your problem right now is that they were mis-linked) and everything will work fine.

Linking error gsoap in mac in c

I try to add gsoap in my application.
I built gsoap for i386.
Created c code with under commands:
wsdl2h -c -s -o soap.h soap.wsdl
soapcpp2 -c -C soap.h
I got files. After this I tried to include these to my app.
I added to my project in xCode. Also I added 6 libraries(libgsoap.a,libgsoap++.a,libgsoapck.a, libgsoapck++.a, libgsoapssl.a, libgsoapssl++.a). I added libraries in Target => Build phases => Link binary with libraries.
But I got error....
ld: duplicate symbol .....
I thought it happened cause in file soapClientLib.c was it:
#ifndef WITH_NOGLOBAL
#define WITH_NOGLOBAL
#endif
#define SOAP_FMAC3 static
#include "soapC.c"
#include "soapClient.c"
Comments for these was:
Use this file in your project build instead of the two files soapC.c and soapClient.c. This hides the serializer functions and avoids linking problems when linking multiple clients and servers
I removed it content.
But after this I got next error...
Undefined symbols for architecture i386:
"_namespaces", referenced from:
_soap_init_LIBRARY_VERSION_REQUIRED_20812 in libgsoap.a(libgsoap_a-stdsoap2.o)
(maybe you meant: _soap_set_namespaces, _soap_set_local_namespaces )
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
And Now I have no idea...
I used gsoap in windows and I added it to my project for 5 minutes. But I wasted much time to add it in mac os.
Can you help me?
I resolved my problem!
I had to do ./configure with keys --disable-namespaces.
Thank you.
But I steal don't understand sense of the file soapClientLib.c.
I know, that this is an old question, but I've just spent an entire evening figuring this out.
Here is a quote from this conversation (another link):
The soapcpp2-generated xyz.nsmap file should be #include'd in your code. It
contains a global XML namespace mapping (or binding) table.
The reason for including this separately is that there are scenarios where the
namespace mapping table is customized or shared.
For instance, I used a C++ classes, generated with soapcpp2 -i <my_header.h>. One of generated files is a <my_service_name>Service.cpp. To get rid of the _namespaces issue I had to #include "<my_service_name>.nsmap" in it.
As for the soapClientLib.c, I's like to quote that conversation again:
Please do not use soapClientLib.c in your build unless you want to combine
multiple separately-generated clients/server codes. This means that the
soapClientLib.c do not include the shared serializers for SOAP headers and
faults.
This problem can be solved with changing compiler filename from gcc to g++.
GCC:
gcc calcmain.cpp soapC.cpp soapcalcProxy.cpp -I/opt/local/include -lgsoap++ -L/opt/local/lib
...
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
G++:
g++ calcmain.cpp soapC.cpp soapcalcProxy.cpp -I/opt/local/include -lgsoap++ -L/opt/local/lib
All OK
Yet you can make it compilable under gcc, with adding an gcc option -lstdc++:
gcc calcmain.cpp soapC.cpp soapcalcProxy.cpp -I/opt/local/include -lgsoap++ -L/opt/local/lib -lstdc++
All OK

C program linking with shared library without setting LD_LIBRARY_PATH

I was reading Introduction to GCC and it says if a package has both .a and .so. gcc prefer the shared library. By default the loader searches for shared libraries only in a predefined set of system directories, such as /usr/local/lib and /usr/lib. If the library is not located in one of these directories it must be added to the load path, or you need to use -static option to force it to use the .a library. However, I tried the following:
vim hello.c:
#include <gmp.h>
#include <stdio.h>
int main() {
mpz_t x;
mpz_init(x);
return 0;
}
gcc hello.c -I/opt/include -L/opt/lib -lgmp (my gmp library is in opt)
./a.out
And it runs. The book says it should have the following error:
./a.out: error while loading shared libraries:
libgdbm.so.3: cannot open shared object file:
No such file or directory
(well, the book uses GDBM as example but I used GMP, but this won't matter right?)
However, I did not set LD_LIBRARY_PATH=/opt/lib, and as you can see I did not use -static option either, but a.out still runs.
Can you all tell me why and show me how to get the error described in the book? Yes I want the error so I will understand what I misunderstood.
From your response to my comment:
linux-gate.so.1 => (0xb7746000)
libgmp.so.10 => /usr/lib/i386-linux-gnu/libgmp.so.10 (0xb76c5000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7520000)
/lib/ld-linux.so.2 (0xb7747000)
So, your program is picking up the lib from /usr/lib.
What you can try to do is rename the lib in your /opt/lib, and link against the new name.
mv /opt/lib/libgmp.so /opt/lib/libgmp-test.so
gcc hello.c -I/opt/include -L/opt/lib -lgmp-test
Then try running the program. Also, compare the result of ldd against the new a.out against what you got before.

Resources