I have a C shared library named libtest.so which in turn use another shared library lihelp.so.
The code for libtest.so use dlopen() to load the libhelp.so
I have integrated libtest.so with my GO script gotest.go
When I run gotest.go after building and installing, I am seeing libtest.so is getting loaded successfully and function in libtest is executed successfully.
But the dlopen() call in libtest.so to load libhelp.so is failining with error "undefined symbol: dlopen"
But if I write a C application which use libtest.so all execution are fine withour any error.
Here is the code snippet of my Go file
/*
#cgo CFLAGS: -I./include
#cgo LDFLAGS: -L. -ltest -ldl
*/
Here is the Makefile entry for building libtest.so
CC = gcc # C compiler
CFLAGS = -c -fPIC -I./include # C flags
LDFLAGS = -shared -L/lib -ldl # linking flags
Can any one suggest what can be the problem?
Output of ldd of my go binary
ldd app
linux-gate.so.1 => (0xb77c3000)
libtest.so => ./libtest.so (0xb77bc000)
libgo.so.5 => /usr/lib/i386-linux-gnu/libgo.so.5 (0xb6ed0000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb6eb2000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb6d03000)
/lib/ld-linux.so.2 (0xb77c4000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb6ce7000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb6ca1000)
Related
The C HelloWorld.so (shared object) is created by linking in a C++ myatomic library. That C++ library uses a Boost Header:
myatomic.cpp
...
#include <boost/system/error_code.hpp>
...
Loading HelloWorld.so with dlopen() returns error: _ZTVN10__cxxabiv117__class_type_infoE
If that Boost header is commented-out, then dlopen() succeeds?
HelloWorld.yaml
...
Common:
Sources:
- Folder: src
Files:
- HelloWorld.h
- HelloWorld.c
ConanLibs:
- CONAN_PKG::myatomic
Linux:
CompilerOptions:
- -fPIC
LinkerOptions:
- -lstdc++
Does Boost C++ under linux need to built with specific options? Maybe gcc vs g++ issues?
Added -lstdc++ to HelloWorld linker options but to no avail. :(
A co-worker discovered this fix
If we're interacting with C++ materials (in this case Boost C++), we
need to be using g++. The gcc tool, even if supplied with a bunch of
-lstdc++ args - does not fill the shoes of the g++ compiler, in terms of things like 'linker/loader hints'
The reason for the error _ZTVN10__cxxabiv117__class_type_infoE is the HelloWorld.so (C program) was not loading a runtime dependent (C++ shared object) libstdc++.so.6. For example,
$ ldd HelloWorldBAD.so
linux-vdso.so.1 (0x00007ffc8a5c5000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f78cf21f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f78cf431000)
$ ldd HelloWorldGOOD.so
linux-vdso.so.1 (0x00007ffd53bba000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f2540003000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f253fe11000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f253fcc2000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2540205000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f253fca7000)
Edit
It was also found that the ordering of the -lstdc++ option is important. (see also this link)
This command correctly includes the C++ runtime dependencies by placing the -lstdc++ option at the END of the build command
/usr/bin/cc -fPIC -O2 -g -DNDEBUG -shared -Wl,-soname,HelloWorld.so ...Lots of Boost Libraries... -lstdc++
whereas putting the option BEFORE the Boost libraries does not
/usr/bin/cc -fPIC -O2 -g -DNDEBUG -lstdc++ -shared -Wl,-soname,HelloWorld.so ...Lots of Boost Libraries...
I'm trying to create a shared library on centos using gcc 4.8.2
shared library code:
//reload.c
int func(int num){
return num++;
}
link command:
gcc -fPIC -shared reload.c -o reload.so
use ldd command:
linux-vdso.so.1 => (0x00007ffe6aa93000)
libc.so.6 => /usr/lib64/libc.so.6 (0x00007f27feb97000)
/lib64/ld-linux-x86-64.so.2 (0x00007f27ff169000)
Now, Want to statically link glibc, how to write it?
like it:
ldd xxx.so
not a dynamic executable
I tried the build options, but the error.
gcc -fPIC -shared reload.c -o reload.so -Wl,-Bstatic -lc
/usr/bin/ld: cannot find -lgcc_s
/usr/bin/ld: cannot find -lgcc_s
collect2: error: ld returned 1 exit status
thank you very much
You do not have dependencies to glibc at all for your code above, so the easiest way is to compile with the flag -nostdlib:
$ gcc -fPIC -shared reload.c -o reload.so -nostdlib
$ ldd reload.so
statically linked
I've compiled source file on host-machine:
g++ -I./source/utils -m32 ./source/services/library_version_info.cpp -o version_info $DAALROOT/lib/ia32_lin/libdaal_core.so $DAALROOT/lib/ia32_lin/libdaal_thread.so -ltbb -liomp5 -lpthread -ldl
# echo $DAALROOT
# /opt/intel/compilers_and_libraries_2016.3.210/linux/daal/
When I'm trying to invoke this on target-machine I get such error:
./version_info: error while loading shared libraries: /opt/intel/compilers_and_libraries_2016.3.210/linux/daal/lib/ia32_lin/libdaal_core.so: cannot open shared object file: No such file or directory
# echo $DAALROOT
# /media/sdcard/daalroot/daal
$LD_LIBRARY_PATH on target-machine contains path to libdaal_core.so, but program does not see that. How can I fix this error?
upd. host g++: 5.4.0, target: 4.9.1
upd2.
ldd version_info
linux-gate.so.1 (0xb77db000)
/opt/intel/compilers_and_libraries_2016.3.210/linux/daal/lib/ia32_lin/libdaal_core.so => not found
/opt/intel/compilers_and_libraries_2016.3.210/linux/daal/lib/ia32_lin/libdaal_thread.so => not found
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x4332e000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x43221000)
libc.so.6 => /lib/libc.so.6 (0x42e7d000)
libm.so.6 => /lib/libm.so.6 (0x43003000)
/lib/ld-linux.so.2 (0x42e50000)
env LD_DEBUG=all ./version_info
408:
408: file=/opt/intel/compilers_and_libraries_2016.3.210/linux/daal/lib/ia32_lin/libdaal_core.so [0]; needed by ./version_info [0]
./version_info: error while loading shared libraries: /opt/intel/compilers_and_libraries_2016.3.210/linux/daal/lib/ia32_lin/libdaal_core.so: cannot open shared object file: No such file or directory
echo $LD_LIBRARY_PATH
/media/sdcard/daalroot/daal/lib/ia32_lin:/media/sdcard/daalroot/daal/../tbb/lib/ia32_lin/gcc4.4
Solution:
g++ -I./source/utils -m32 ./source/services/library_version_info.cpp -o version_info -l daal_core -l daal_thread -ltbb -liomp5 -lpthread -ldl
I am linking an so, that depends on libmxml.so. However I have no rights install libmxml.so.
So thats what I am doing
gcc -shared -m32 -o ServiceProvider.so ServiceProvider.o -L ../../../../system/addonlibs/ -lmxml -lpthread
ldd shows me
ldd ServiceProvider.so
libmxml.so.1 => not found
libpthread.so.0 => /lib/libpthread.so.0 (0x40026000)
libc.so.6 => /lib/libc.so.6 (0x40046000)
the second try was
gcc -shared -m32 -o ServiceProvider.so ServiceProvider.o ../../../../system/addonlibs/libmxml.so -lpthread
and still ldd shows me
ldd ServiceProvider.so
libmxml.so.1 => not found
libpthread.so.0 => /lib/libpthread.so.0 (0x40026000)
libc.so.6 => /lib/libc.so.6 (0x40046000)
Consequently, ldd does not find the library, since I only have "libmxml.so", but no "libmxml.so.1". How do I get rid of this ".1" suffix? Why is it comming?
When you link with a dynamic library, you should not do :
gcc -shared -m32 -o ServiceProvider.so ServiceProvider.o ../../../../system/addonlibs/libmxml.so -lpthread
Instead, make sure that /yourpath/system/addonlibs (you should use the full path instead of a relative one) is in you LIBRARY_PATH. Then change you link command.
export LIBRARY_PATH=/yourpath/system/addonlibs:$LIBRARY_PATH
gcc -shared -m32 -o ServiceProvider.so ServiceProvider.o -lmxml -lpthread
You can also write that:
gcc -shared -m32 -o ServiceProvider.so ServiceProvider.o -L/yourpath/system/addonlibs -lmxml -lpthread
However, to run your program, you will need to have your library path in LD_LIBRARY_PATH.
If you have issues with .soand .so.1 stuff, then rename your .so to .so.1 and make a symlink from .so.1 to .so.
Edit:
If you do objdump -p libmxml.so | grep SONAME you will probably get libmxml.so.1.
It is where you get the libmxml.so.1 identifier.
I want to compile C code into one monolithic executable file (include every dependencies in this file) using GCC.
Usually I can compile the code with this command:
gcc -o server ex-serv-x509.c -lgnutls
But when I try to compile it with this -static argument I get this error:
[root#localhost test]# gcc -static -o server ex-serv-x509.c -lgnutls
/usr/bin/ld: cannot find -lc
collect2: ld returned 1 exit status
[root#localhost test]#
How I can solve the problem?
Best wishes
Try using the ldd command to see what it's linking in without the -static option. Here's what I get for a silly program I have.
~$ gcc so.o -lm -o so
~$ ldd so
linux-gate.so.1 => (0x00db7000)
libm.so.6 => /lib/libm.so.6 (0x00c7f000)
libc.so.6 => /lib/libc.so.6 (0x0037f000)
/lib/ld-linux.so.2 (0x002da000)
~$ gcc so.o -static -lm -o so
~$ ldd so
not a dynamic executable
So without the static I automagically get the shared version of libc, which surprised me even though it should not have. I imagine you have the shared version but not the static, so you'll need to get the static library from somewhere if you have decided that 1986 is the year for you :-).
To make sure you can do: gcc -print-search-dirs and search through them and make sure that libc.a is not to be found.