I link a shared library on the command line while building an executable. Running ldd on that executable is not showing the linked shared library.
After looking at some of the output of the linker, I have even tried adding the -Wl,--no-as-needed option and that didn't help either.
foo.c:
#include <stdio.h>
void foo () {
printf ("Hello world\n");
}
main.c:
#include <stdio.h>
int main () {
printf ("In main \n");
foo ();
}
Here's the command I used to compile and link:
$ gcc -Wl,--no-as-needed main.c -o main -L./ -lfoo
/bin/ld: cannot find -lfoo
collect2: error: ld returned 1 exit status
$ gcc -c foo.c -shared -Wl,-soname,libfoo.so -o libfoo.so
$ ls -l libfoo.so
-rw-r--r-- 1 apple eng 1488 Jun 4 04:44 libfoo.so
$ gcc -Wl,--no-as-needed main.c -o main -L./ -lfoo
$ ldd main
linux-vdso.so.1 => (0x00007fffbdd6c000)
libc.so.6 => /lib64/libc.so.6 (0x00007f6367e23000)
/lib64/ld-linux-x86-64.so.2 (0x00005556e268a000)
libfoo.so does not show up above.
$ objdump -x main | grep NEEDED
NEEDED libc.so.6
Why isn't libfoo.so showing up as NEEDED?
By using the gcc option -c you're telling it to create only object from foo.c, so the only product you're getting from this gcc command is an object file. The fact that its suffix is .so is only because you forced it using -o option. If you run this command without -o you'd see that the output is just foo.o - an object file.
If you omit the -c from the gcc command you'd get the shared object you wanted.
Running file on the output file shows the difference (note that I'm not setting the output name using -o and letting gcc use its default names):
With -c:
> gcc -c foo.c -shared
> file foo.o
foo.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
Without -c:
> gcc foo.c -shared
> file a.out
a.out: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=a63581bfc45f845c501ffb6635, not stripped
^^^
|||
This command does not generate a shared library:
gcc -c foo.c -shared -Wl,-soname,libfoo.so -o libfoo.so
It generates an object file libfoo.so that is later statically linked with your code. Proof: remove the lib file, the program will still run.
Solution:
Compile the object file separately, then convert it into a shared library. You will have to tell the loader where to search for the shared libraries by setting LD_LIBRARY_PATH:
gcc -c foo.c
gcc foo.o -shared -o libfoo.so
gcc main.c -o main -L./ -lfoo
export LD_LIBRARY_PATH=`pwd`
ldd ./main
# linux-vdso.so.1 (0x00007ffe0f7cb000)
# libfoo.so => /home/---/tmp/libfoo.so (0x00007f9bab6ec000)
# libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9bab2fb000)
# /lib64/ld-linux-x86-64.so.2 (0x00007f9babaf0000)
Related
How to use nasm to create gui under linux
I found an example ,https://gist.github.com/nikAizuddin/6fbbc703f1213ab61a8a
but i get an error
nasm main.asm -o main.o -felf64 -w+all -gstabs
ld main.o -o a -melf_x86_64 -dynamic-linker /lib/ld-linux.so.2 -lX11
print zsh: accessing a corrupt shared library: ./a
what happened?
I'm failing to load a shared object library with python. I've tried setting the LD_LIBRARY_PATH to where the someObject.o is located and that works when I am using non-sudo command to run the python script but when I use sudo I run into a linking error.
OSError: bbumintflib.o: cannot open shared object file: No such file or directory
Does anyone know how to link a .o file to the .so file?
using ldd, I know the .so cannot find the .o file.
>>>ldd someSharedObject.so
linux-vdso.so.1 (0x00007ffca69af000)
someObject.o => not found
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f53c96b8000)
/lib64/ld-linux-x86-64.so.2 (0x00007f53c9a57000)
Edit:
This is how I am building the object and sharedObject files
gcc -I ../include -I../../module1/include -I ../../module2/include --shared -fPIC someCFile.c -o someObject.o plat_linux.c
gcc someObject.o -shared -o someSharedObject.so
This is your problem:
gcc -I ../include -I../../module1/include -I ../../module2/include --shared -fPIC someCFile.c -o someObject.o plat_linux.c
gcc someObject.o -shared -o someSharedObject.so
The first command produces a shared library with odd name someObject.o.
The second command links a new shared library named someSharedObject.so, which depends on someObject.o.
To fix this, do this:
gcc -I ... --shared -fPIC someCFile.c plat_linux.c -o someSharedObject.so
I am creating an exe and shared library in cygwin.
The library is created and is in the proper place, but when I try to compile the client code daemon, the linking phase says that it can't find the sysutil library.
Error is posted below:
/usr/lib/gcc/i686-pc-cygwin/5.4.0/../../../../i686-pc-cygwin/bin/ld: cannot find -lsysutil
collect2: error: ld returned 1 exit status
make: *** [Makefile:84: daemon] Error 1
I tried exporting the path using LD_LIBRARY_PATH but unfortunately that also didn't help.
daemon.c
#include <stdio.h>
#include <sys_util.h>
int main(){
sys_util();
while(1){
}
return 0;
}
sysutil.c
#include <stdio.h>
#include "sys_util.h"
int sys_util(){
return 0;
}
sysutil.h
int sys_util();
test.bat
g++ -fpic -c sysutil.c
g++ -shared -o libsysutil.so sysutil.o -I.
g++ -c daemon.c -I.
g++ -o daemon.exe daemon.o -L. -lsysutil
del *.o
Shared library is generated sysutil.so in the folder c:/test same as the source code (daemon.c,sysutil.c,sys_util.h,test.bat,libsysutil.so)
Cygwin console output:
/cygdrive/c/test
$ ./test.bat
C:\test>g++ -fpic -c sysutil.c
sysutil.c:1:0: warning: -fpic ignored for target (all code is position independent)
C:\test>g++ -shared -o libsysutil.so sysutil.o -I.
C:\test>g++ -c daemon.c -I.
C:\test>g++ -o daemon.exe daemon.o -L. -lsysutil
c:/mingw/bin/../lib/gcc/mingw32/5.3.0/../../../../mingw32/bin/ld.exe: cannot find -lsysutil
collect2.exe: error: ld returned 1 exit status
C:\test>del *.o
Cygwin expects shared libraries to have the .dll extension.
Change the second line in your batch file to:
g++ -shared -o sysutil.dll sysutil.o -I.
See the users' guide for more info:
https://cygwin.com/cygwin-ug-net/dll.html
I am currently using the following method to create shared libraries:
gcc -c test1.c -fPIC -o test1.o
gcc -c test2.c -fPIC -o test2.o
...
gcc test1.o test2.o ... -shared -o libtest.so
How can I do this same task with libtool? This is what I have done so far:
libtool compile gcc -c test1.c -o test1.o
libtool compile gcc -c test2.c -o test2.o
...
libtool link gcc test1.lo test2.lo ... -o libtest.la
However, this only creates libtest.la and libtest.a. I need the shared library libtest.so.
Try to add -rpath option like:
libtool --mode=link gcc -o libtest.la test1.lo -rpath /tmp
-rpath option tells Libtool where to install the library
If the path's missed, it won't generate the shared library.
I was bothered by this problem for quite a while until later I read carefully through the log file from configure, the script detects that LD was not able to generate dynamic linked file (.so). The problem was my environment variable LD was set to g++. Unset it or change to ld fixed the problem.
Here's my code.
#include <thread>
#include <iostream>
//#include <ctime>
using namespace std;
void f() {}
int main() {
//struct timespec t;
//clock_gettime(CLOCK_REALTIME, &t);
thread(f).join();
return 0;
}
I have tried to compile this program in the following ways:
1. g++ a.cc -o a -std=c++11 -pthread
2. g++ a.cc -o a -std=c++11 -lpthread
3. g++ -pthread a.cc -o a -std=c++11
4. g++ a.cc -c -std=c++11 && g++ a.o -o a -lpthread
5. g++ a.cc -c -std=c++11 -pthread && g++ a.o -o a -pthread
All of them can output the executable "a". However, none of them seem to link the library "libpthread.so":
./a
terminate called after throwing an instance of 'std::system_error'
what(): Enable multithreading to use std::thread: Operation not permitted
Aborted
ldd ./a
linux-vdso.so.1 => (0x00007fff997fe000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f350f7b5000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f350f59f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f350f1d6000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f350eed2000)
/lib64/ld-linux-x86-64.so.2 (0x00007f350fad4000)
But, the following way works perfectly:
uncomment all the three lines in the above code(must do this, or the same error appears);
using "g++ a.cc -std=c++11 -o a -lrt".
I'm using ubuntu 13.10. Any reason for this?
This would seem to be a known Ubuntu related bug.
You can (as noted on the linked page) work around it by passing -Wl,--no-as-needed on the command line;
> g++ a.cc -pthread -std=c++11
> ./a.out
terminate called after throwing an instance of 'std::system_error'
what(): Enable multithreading to use std::thread: Operation not permitted
>
> g++ a.cc -pthread -std=c++11 -Wl,--no-as-needed
> ./a.out
>