I am having .c and .so file. I tried by using the following compilation: gcc main.c -ldl. In that .c file i linked to .so file through dlsym(). How to compile using .so file with .c.
Probably you can do this:
when linking do:
g++ -o prog prog.o -ldllname
If libdllname.so is not in the system directory then add its directory to the library path:
g++ -o prog prog.o -L/path/to/my/library/folder -ldllname
This is based on your further comments. First guard the declarations of your header file.
#ifndef HEADER_PROTECT
#define HEADER_PROTECT
---------- Here is the content of header
#endif
Next, check in your code, are you defining multiple definitions. Or are you re-defining the standard functions again? Can you please post your code to guide you better?
Looks like you have re-defined Close_Comm(), can you check it? Error says that the definition is there in main.c also.
The following is the general way to compile shared object and link it.
To compile shared objects.
-g : for debug information
fPIC: for position independent code
$gcc -fPIC -g myfile
The following will create the shared object libmyfile.so
$gcc -shared -o libymyfile.so myfile.o
Now,In order to link it with your main.c.
I assume that the libmyfile.so is in your current path, thus -L./
$gcc main.c -o main.out -L./ -lmyfile
Now, you need to export the LD_LIBRARY_PATH on the bash; in order to execute the binary.
$LD_LIBRARAY_PATH=$LD_LIBRARAY_PATH:./
$./main.out
The dlsym is to load the symbol from the shared object at the run-time. If you want to load the shared object at run time, this can be used. The following is one of the example of dlsym Hack the standard function in library and call the native library function afterwards
dlsym() is used to find a symbol in an open library file.
you first need to use dlopen() in order to open the file, and only then use dlsym()
Related
I've been playing around with GCC lately and have been experimenting with the linking options. I'm somewhat confused why the link option -l is necessary when statically linking to an archive file. It seems like you can just toss the .a file as if it were an ordinary object file.
For example, take the following make file:
test1 : main.c libfunc.a
gcc main.c -L. -lfunc -o main.out
test2 : main.c libfunc.a
gcc main.c libfunc.a -o main.out
libfunc.a : func1.c func2.c
gcc func1.c -c
gcc func2.c -c
ar cr libfunc.a func1.o func2.o
Make target test1 uses GCC's linking options to link to the archive file. Target test2 instead just includes the archive file direct. Building and running each output seem to result in the same executable.
There are several ways you can tell gcc what file(s) to use. An argument of the form -lname (or the two arguments -l name) says “Search for a library named name”. Per the GCC documentation, this argument is passed to the linker (typically the ld command). The linker looks for a file with a name like libname.extension, where extension is one of the known library files extensions such as .a or .so, and it looks for files with those names in a list of library directories it has. You can add directories to search with the -L switch.
When the linker finds the library, it uses it just as if you had specified the path, so the end result is the same whether you specify the library with -l or with its path.
By using the path, you can specify libraries that are not in the known library directories or that have unusual names.
Note that the linker does not process libraries the same way as object files. When the linker processes an object file, it incorporates everything in the object file into the output file being constructed. When the linker processes a library file, it incorporates only those modules within the library that provide a symbol definition for a symbol referenced by a prior module and not yet resolved. For example, if you write a program that uses sqrt but does not use sin, then, when the linker processes libm.a after reading your object module, it will take the sqrt module from the library but not the sin module.
Currently I have two files
main.c
libxxx.a
main.c references some functions defined in the source code of a relocatable object file in libxxx.a.
Now the following command successfully compiles main.c and links it to libxxx.a:
gcc -o prog main.c libxxx.a
but if I put libxxx.a into one of the search paths of ld, the same directory with libc.a,
gcc -o prog main.c
just doesn't work. It seems that ld fails to find this archive file when searching in the directory. Can someone tell me why this happens?
but if I put libxxx.a into one of the search paths of lb linker, the same directory with libc.a,
gcc -o prog main.c
just doesn't work.
That is expected and desired: you wouldn't want every program you write to link against every library that is installed in the system search path. What you want is:
gcc -o prog main.c -lxxx
That is: copying the library into /usr/lib allows the linker to find it without any extra search arguments, but you still must tell the linker that you want to link against libxxx.
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 been following these instructions(http://jonisalonen.com/2012/calling-c-from-java-is-easy/) on how to create a shared library, but these instructions only show how to do it with one file. When I use this file, that I made into a shared library, the .so file can't call other .c files in the same place. How do i compile all the c files so that i can make a merged shared library that is accessible through java?
1) Create your object files with -fPIC:
gcc -fPIC -c file1.c
This creates file1.o. (same for file2.c, file3.c and so on).
2) Link it in a shared library.
gcc -shared -o library.so file1.o file2.o file3.o
Adjust accordingly for additional compiler flags, include paths from other stuff you're using etc.
I'm using a pre-built library called 'libdscud-6.02.a', which includes a lot of low level I/O calls for some specific hardware. From this, I created some wrapper functions which I compiled into an object file called 'io.o'.
Now, I have a few programs which I'm compiling with these I/O functions and instead of having to do this:
gcc libdscud-6.02a io.o -o test test.c
I would like to just have this:
gcc io.o -o test test.c
Is there any way to link the .a file into the .o file so I only need to include the .o file when compiling binaries?
You could do the opposite and add the io.o file to the .a file using ar:
ar q libdscud-6.02.a io.o
One solution would be simply to use a make variable:
IO_STUFF = libdscud-6.02a io.o
...
$(CC) $(IO_STUFF) ...
AFAIK it is not possible to link .a library and .o file to create another intermediate file i.e. file which is not linked like .o file.
The solution provided by Burton Samograd look like a very good option; but in case you are not allowed to modify .a library file then you can follow suggestion provided by DarkDust in case you are building using make.
However you can create a shared library .so file, from a .a library file and .o file (I think that is what Michael Burr is trying to convey). You can use only the shared library instead of both .a & .o file to generate your executable as follows:
Generate shared library gcc io.o libdscud-6.02.a -shared -o io.so (Please note that the order of files passed for linking is important)
Build your source with gcc io.so -o test test.c . To execute your executable path of io.so should be in the look up path of loader (ld) i.e. LD_LIBRARY_PATH.
The right way to work with shared object would be to create a libio.so which is the naming convention and not io.so and build code as gcc test.c -o test -L<path_to_libio.so> -lio and path to libio.so should be in ld's look up path for executing the output executable.
I know creating shared library just to avoid addition of another file for compilation does not seem to be what you want to do ...but it is just for your info in case you didn't already know :)