The problem is this: I wrote a simple program that uses FFMPEG. compile as follows:
gcc -lavcodec -lavformat -lavutil -c test.c
gcc -lavcodec -lavformat -Lavut -o test test.o
Compiled without problems, test file appears, but when you start:
. / test
An error occurs:
. / test: error while loading shared libraries: libavcodec.so.53: cannot open shared object file: No such file or directory
At what ffmpeg was originally built and installed and the file libavcodec.so.53 there. In what may be the problem?
You appear to be linking against libraries in a custom library directory, -Lavut.
Check where your loader looks for the executable's libraries:
ldd ./test
If any of them are in non-standard directories (and ldd indicates that a particular library couldn't be found), append those to the LD_LIBRARY_PATH:
LD_LIBRARY_PATH=/tmp/work/avut ./test
If you like, you can hardcode the library path into the executable with the -rpath linker option, e.g. gcc ... -Wl,-rpath -Wl,/tmp/work/avut.
Related
I have been trying to compile a C source file (driver.c) with a main method with a dynamic library (libhello.so) file that has all the implementations of the functions used in the main method.
I make the .so file with
gcc -shared -o libhello.so -fPIC hello.c
It compiles fine and returns the file in the directory as expected.
Then I try to compile the driver.c file with the dynamic library libhello.so with
gcc driver.c libhello.so -o driver
It compiles without complaint and the issue happens when I try to run the executable "driver". I get the follwing error:
./driver: error while loading shared libraries: libhello.so: cannot open shared object file: No such file or directory
I'm confused because the file is literally right there in the directory of which it is being compiled in. Can someone explain this for me?
Actually you do not dynamically link with libhello.so. You need -l option.
-lhello
You can check dependencies with ldd driver (your exec).
regarding:
gcc driver.c libhello.so -o driver
is not correct.
It should be similar to:
gcc driver.c -o driver -L. -lhello
of course, there should be a header file that contains all the prototypes, etc for the library libhello.so
That header file typically would be named: hello.h so the final compile+link statement would be:
gcc driver.c -o driver -I. -L. -lhello <<< edited
I made a misstate, The last line, the '-I' parameter should list the directory for the header file, not the header file name
I have a project struct of a lib like this:
lib_ode/
src/
main/
c/
ode.c
incluce/
ode.h
test/
c/
test_ode.c
include/
target/
.objs/
test/
In this struct I had compile my project with those 4 commands:
(creating lib object)
gcc -fPIC -O3 -DNDEBUG -g -Wall -Isrc/main/include -c -o "target/.objs/ode.o" src/main/c/ode.c
(creating lib)
gcc -shared target/.objs/ode.o -lm -o "target/libode.so"
(creating test object)
gcc -fPIC -O3 -DNDEBUG -g -Wall -Isrc/main/include -c -Isrc/test/include -o target/.objs/test.o src/test/c/test_ode.c
(creating test)
gcc -L./target -lode target/.objs/test.o -o target/test/test.out
Then I tryed to run target/test/test.out and got this error.
target/test/test.out: error while loading shared libraries: libode.so: cannot open shared object file: No such file or directory
In my understand, -L option includes a folder for link, and after the second command I can find a file at target/libode.so.
So what am I doing wrong?
You have created an executable dynamically linked against a library in an arbitrary directory. At runtime, the dynamic linker cannot find the library (it doesn't exist in any of the standard search paths) and so gives you the error.
To run the program, you could set the LD_LIBRARY_PATH environment variable:
LD_LIBRARY_PATH="`pwd`/target" target/test/test.out
You could also trying linking with -rpath (I've not tried this):
gcc -L./target -Wl,-rpath,./target -lode target/.objs/test.o -o target/test/test.out
(The above should "hardcode" the additional dynamic library search path in the executable. If you later move the library you will get an error again. I'm not sure if the path stored in the executable will be relative or absolute; if it's relative, you'll need to keep the executable and library at the same path relative to each other).
I have static library lib.a and in all tutorials using:
gcc -o main main.o -L. -lib
But I cant, I have errors:
/usr/bin/ld: cannot find -lib
collect2: error: ld returned 1 exit status
I need to use:
gcc -o main main.o -L. -lib.a
Why? What should I do to repair it ?
From the documentation of gcc -l:
-llibrary:
The linker searches a standard list of directories for the library, which is actually a file named liblibrary.a. The linker then uses this file as if it had been specified precisely by name.
...
The only difference between using an -l option and specifying a file name is that -l surrounds library with ‘lib’ and ‘.a’ and searches several directories.
So you cannot use -l with a library named 'lib.a'. Use 'lib.a' without the -l to include it. Of course, you cannot use -L then to set the directories to be searched for this particular library.
Do you have the error with this line ?
gcc -o main main.o -L. -llib
As MicroVirus found in the documentation, you will have to rename your library in liblib.a to use my previous line or just pass your library to gcc like a simple file.
I have got the object-file from source code using MinGW.
But on linking:
ld -o test.exe test.o
I get errors, for example the following:
undefined reference to printf
First, why are you using ld directly?
The following is an excerpt from the "GCC and Make" tutorial found at http://www3.ntu.edu.sg/home/ehchua/programming/cpp/gcc_make.html.
Compile and Link Separately
The above command compile the source file into object file and link with other object files (system library) into executable in one step. You may separate compile and link in two steps as follows:
// Compile-only with -c option
> g++ -c -Wall -g Hello.cpp
// Link object file(s) into an executable
> g++ -g -o Hello.exe Hello.o
Note g++ (you can substitute gcc if you are using C and not C++) is used both for compiling and linking. ld is not used at all.
The benefit of using g++ or gcc to link is that it will link with default libraries, such as the one you need to link with for printf, automatically.
To link with other libraries, you specify the library name with the -l parameter, as in -lmylib.
We can view commands ran by compiler via command
c99 -v test.o
We'll get some text. All after string which contains "COLLECT_CGG_OPTIONS" will be arguments of ld.
But size of executable file is much more then size of file got by previous way.
I'm trying to compile my code with a DLL i made and I get the error below when i write ./prog
./prog: error while loading shared libraries: libctest.so.1: cannot open shared object file: No such file or directory
I followed the tutorial here and my mono app has no problem loading the dll and calling the functions. The key parts of the tutorial were
gcc -Wall -fPIC -c *.c
gcc -shared -Wl,-soname,libctest.so.1 -o libctest.so.1.0 *.o
mv libctest.so.1.0 /opt/lib
ln -sf /opt/lib/libctest.so.1.0 /opt/lib/libctest.so.1
ln -sf /opt/lib/libctest.so.1.0 /opt/lib/libctest.so
My C# code does
[DllImport("path/to/CDLL", CallingConvention = CallingConvention.Cdecl)]
public static extern void test();
I built with
gcc -Wall -L/opt/lib main.c -lctest -o prog
This is the first thing i changed. prog.c to main.c. From there I simply run with ./prog to get the error at the top of this question. I do this as root so there shouldn't be permission issues. I also chmod 755 the so's. What am I doing wrong? This is opensuse. I had to create the /opt/lib so I am thinking this path isn't registered where it should be
The dynamic linker ld.so will not look in /opt/lib by default when attempting to resolve library dependencies. You have to tell the linker about the non-standard library directories or add the /opt/lib path to your prog binary.
eg
LD_LIBRARY_PATH=/opt/lib ./prog
or, link prog with the -rpath linker option. This provides an additional path for the linker to search when resolving locations of shared objects.
gcc -Wall -L/opt/lib -Wl,-rpath,/opt/lib main.c -lctest -o prog
You can use the ldd command on a binary to show the locations of shared libraries.
ldd prog
This will currently show that libctest.so cannot be found. With an additional search path, the following command should show that all libraries are resolved:
LD_LIBRARY_PATH=/opt/lib ldd prog