I have a very simple command-line that I use for this. This seems to
work the same for Sun's Workshop 4.2 C compiler as it does for the GNU C
compiler. Both are on my Sparc Solaris 2.51 workstation. To compile the
modules for you library:
cc -o object.o -c -KPIC -I<include path> source.c
To link the objects into the shared object library:
ld -G -L<path to other libs to link in, if any> -o<output file name.so>
<.o object modules>
Then, when you compile/link your program with the .so file from above:
cc -o <executable name> -I<path to header files> -L<path to .so
libraries> -ldl <C source code>
The important part above is to link in libdl.so with the -ldl
option. This links in the dynamic linking facilities which allows you to
use dlopen, etc. In fact, I followed the example from the dlsym(3X) man
int *iptr, (*fptr)(int);
/* open the needed object */
handle = dlopen("/usr/home/me/libfoo.so.1", RTLD_LAZY);
/* find the address of function and data objects */
fptr = (int (*)(int))dlsym(handle, "my_function");
iptr = (int *)dlsym(handle, "my_object");
/* invoke function, passing value of integer as a parameter */
The only thing I'm not sure about is if the object modules which are
linked in to the .so library have to be compiled to have position
independent code (-KPIC) or not. I am using an existing .a archive which
I converted into a .so library and am trying to call functions from it
with the above method. The dlopen() and dlsym() work OK, but the call to
the module hangs. Does anyone know if the modules in a .so library have
to be compiled to be position independent before they can be used via
dlopen(), dlsym(), etc?
> We are using Solaris 2.5. We have 3 to 4 shared libraries. In our
> application we are trying to open them
> using the dlopen() command. We used the
> ld -G ......
> compile options to create the shared library. But then the dlopen()
> Can someone help us out here with the right --
> - Compile and link options to create a shared library....
> - using the dlopen() to open the created shared library.
> We are in a crunch time right now.
> Any input or help is appreciated. Email back at
> Uday Pai