I compiled the original cwm tgz package (not the netbsd one) with
./configure
make
which works without error. After starting cwm with
./cwm
the error
Shared object "libX11.so.7" not found
appears. The ldd output is:
-lXft.2 => /usr/pkg/lib/libXft.so.2
-lfontconfig.1 => /usr/pkg/lib/libfontconfig.so.1
-lfreetype.7 => /usr/X11R7/lib/libfreetype.so.7
-lz.1 => /usr/lib/libz.so.1
-lgcc_s.1 => /usr/lib/libgcc_s.so.1
-lc.12 => /usr/lib/libc.so.12
-lbz2.1 => /usr/lib/libbz2.so.1
-lexpat.2 => /usr/lib/libexpat.so.2
-lXrender.2 => /usr/X11R7/lib/libXrender.so.2
-lXext.7 => /usr/X11R7/lib/libXext.so.7
-lX11.7 => /usr/X11R7/lib/libX11.so.7
-lxcb.1 => /usr/X11R7/lib/libxcb.so.1
-lXau.7 => /usr/X11R7/lib/libXau.so.7
-lXdmcp.7 => /usr/X11R7/lib/libXdmcp.so.7
-lX11.7 => not found
-lXext.7 => not found
where the "not founds" refer to the cwm binary directly. It has been linked with the command
gcc -Wall -Icompat -D_REENTRANT -I/usr/pkg/include\
-I/usr/X11R7/include/freetype2 -I/usr/X11R7/include\
-I/usr/X11R7/include/freetype2 -I/usr/X11R7/include -g -O2\
-I/usr/X11R7/include -o cwm calmwm.o draw.o screen.o xmalloc.o\
client.o grab.o search.o util.o xutil.o conf.o input.o xevents.o\
group.o geographic.o kbfunc.o cursor.o font.o -L/usr/pkg/lib\
-Wl,-R/usr/pkg/lib -lXft -L/usr/X11R7/lib -lX11 -lXext
so the linker should find libX11 and libXext.
Why does the loader complain?
The obvious portion is that ``-Wl,-R/usr/X11R7/lib'' was not included on the loader command line at link time.
NetBSD's runtime loader (/libexec/ld.elf_so) has only the runtime library search path of ``/lib:/usr/lib'' compiled in, so any executable needing additional elements on the search path needs to explicitly add them at compile time. (like the entry for /usr/pkg/lib.)
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 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)
I installed glibc-2.18 into my home directory and want to link an application against it:
$ g++ -pthread -o tsx_test tsx_test.cpp -Wl,--rpath=/home/hl/lib/ \
-Wl,--dynamic-linker=/home/hl/lib/ld-linux-x86-64.so.2
Compiling and linking works fine using g++4.7.3, however, fails when executing it:
$ ./tsx_test
./tsx_test: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
/usr/lib/x86_64-linux-gnu/libstdc++.so.6 definitely exists, when I compile without "--rpath" the same libstdc++.so.6 is linked and everything works fine.
$ ldd tsx_test
linux-vdso.so.1 => (0x00007fff42bd4000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f42aa3aa000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f42aa194000)
libpthread.so.0 => /home/hl/lib/libpthread.so.0 (0x00007f42a9f75000)
libc.so.6 => /home/hl/lib/libc.so.6 (0x00007f42a9bc8000)
libm.so.6 => /home/hl/lib/libm.so.6 (0x00007f42a98c5000)
/home/hl/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f42aa6c9000)
/usr/lib/x86_64-linux-gnu/libstdc++.so.6 definitely exists
... but your libc doesn't look there.
You can set your RPATH like so: -Wl,-rpath=/home/hl/lib:/usr/lib, or you can edit /home/hl/etc/ld.so.conf and tell your libc to look in /usr/lib (after /home/hl/lib).j
Is it a permission problem, can't I mix root owned and user owned libs?
No. You can definitely mix and match root-owned and user-owned libraries.
How correct linking with libperl.so
I use Fedora Core 16 and try to compile program with embedding perl follows way:
gcc -W -Wall -g -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -I. -I/usr/include -I/usr/lib/include -I/usr/lib/perl5/CORE -c program.c
gcc -L/lib -L/usr/lib/perl5/CORE -lperl -o program.run program.o
After trying to run program I getting following message:
error while loading shared libraries: libperl.so: cannot open shared object file: No such file or directory
if execute following command 'ldd program.run' then it output to console
ldd ./program.run
linux-gate.so.1 => (0xb7751000)
libperl.so => not found
libc.so.6 => /lib/libc.so.6 (0x4eea5000)
/lib/ld-linux.so.2 (0x4ee80000)
Yes i can set LD_LIBRARY_PATH environment variable and program will be work, but if i execute same command for '/usr/bin/perl' library will be found without setting specific environment variable e.g
ldd `which perl`
linux-gate.so.1 => (0xb77f4000)
libperl.so => /usr/lib/perl5/CORE/libperl.so (0xb767b000)
libresolv.so.2 => /lib/libresolv.so.2 (0x4f22f000)
libnsl.so.1 => /lib/libnsl.so.1 (0x42eaf000)
libdl.so.2 => /lib/libdl.so.2 (0x4f055000)
libm.so.6 => /lib/libm.so.6 (0x4f085000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x41ee6000)
libutil.so.1 => /lib/libutil.so.1 (0x42ecc000)
libpthread.so.0 => /lib/libpthread.so.0 (0x4f05c000)
libc.so.6 => /lib/libc.so.6 (0x4eea5000)
/lib/ld-linux.so.2 (0x4ee80000)
libfreebl3.so => /lib/libfreebl3.so (0x42492000)
How correct link program with libperl.so
Adding -Wl,-rpath -Wl,/usr/lib/perl5/CORE (when linking) should help.
You need to set LD_LIBRARY_PATH at runtime for the dynamic linker to find libperl:
LD_LIBRARY_PATH=/usr/lib/perl5/CORE ./program
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.