Shared Library On Solaris 10 using g++ 3.4.3

[Bala]

Hello,

I am trying to create a shared library on solaris. The inputs to this
library is a source file and then 2 static libraries.

I need to call code within the shared library in another application
which in turn will use the static libraries for further processing.

This is the command i am using to build the shared library

g++ -Wno-deprecated -DSOLARIS -DSUN4 -DSUN -DSVR4 -
D_POSIX_PTHREAD_SEMANTICS
-I/usr/java/include -I/usr/java/include/solaris -I/home1/users/biyer/
Bala/OAPI/include
-I/home1/users/biyer/Bala/OAPI/src ../lib/liba ../lib/libb Common.C -o
Common.o

g++ -fpic -D_REENTRANT -shared Common.o -o libSubscribe.so

Though the file that i have included in Common.C has declaration for
the method ULIST_create that i am calling from Common.C, it still
gives me a compilation error
Undefined first referenced
symbol in file
ULIST_create() /var/tmp//ccxiLplo.o

I get similar errors for every method that i am trying to call from
Common.C which are defined in the static libraries.

Am I creating the shared library the way it should be created? Can you
please let me know where its going wrong?

Thanks in advance

[James Kanze]

On Nov 13, 12:02 am, Bala <[e-mail]:

On Nov 9, 5:01 am, James Kanze <[e-mail]:

On Nov 8, 8:50 pm, Bala <[e-mail]:

[...]

I was able to create the shared libraries and run it properly. Thanx
for all the help. But i cant g o ahead with g++ because one of those
static libraries has been compiled with Sun studio CC 5.8. The mangled
names are too different and it gives me runtime errors while trying to
resolve those.

Not just the mangled names. The class layout is different as
well. The mangled names are intentionally different, because if
you could link, all you'd get is a core dump (or some other
strange behavior) at runtime.

I planned to move my application to CC instead but this is
giving me another strange problem.

Be very, very careful. The libraries (both alternatives)
available with CC are really bad.

I created a shared library using CC with the following command

CC -G -D_REENTRANT -DSOLARIS -DSUN4 -DSUN -DSVR4 -
D_POSIX_PTHREAD_SEMANTICS -I/usr/java/include -I/usr/java/include/
solaris -I/home1/users/biyer/Bala/OAPI/include -I/home1/users/biyer/
Bala/OAPI/src Common.cpp liba.a libb.b -o libSubscribe.so

Then i compiled my source as
CC -DSOLARIS -DSUN4 -DSUN -DSVR4 -D_POSIX_PTHREAD_SEMANTICS -I/home1/
users/biyer/Bala/OAPI/include -I/home1/users/biyer/Bala/OAPI/src
Main.cpp -o Main.o

Now when i run Main.o it says its not able to open the shared
library. It prints an error message which is part of my code.
"Error Loading the Dynamic Library"

This is really getting off topic, but what does dlerr() say?

Just a hunch, however: you need a -ldl at the end of your link
line. Otherwise, you just get stubs for dlopen et al. (I'll
admit that I don't understand this. By default, the system
libraries are loaded dynamically, so the guts of libdl must be
there, even if you don't specify it.)

Maybe the g++ driver adds this automatically. (I have it in my
Linux builds with g++, however. I don't know if it's necessary,
however. I know I needed it once, and I probably just threw it
in everywhere.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Bala]

On Nov 13, 4:56 am, James Kanze <[e-mail]:

On Nov 13, 12:02 am, Bala <[e-mail]:

On Nov 9, 5:01 am, James Kanze <[e-mail]:

On Nov 8, 8:50 pm, Bala <[e-mail]:

[...]

I was able to create the shared libraries and run it properly. Thanx
for all the help. But i cant g o ahead with g++ because one of those
static libraries has been compiled with Sun studio CC 5.8. The mangled
names are too different and it gives me runtime errors while trying to
resolve those.

Not just the mangled names. The class layout is different as
well. The mangled names are intentionally different, because if
you could link, all you'd get is a core dump (or some other
strange behavior) at runtime.

I planned to move my application to CC instead but this is
giving me another strange problem.

Be very, very careful. The libraries (both alternatives)
available with CC are really bad.

I created a shared library using CC with the following command
CC -G -D_REENTRANT -DSOLARIS -DSUN4 -DSUN -DSVR4 -
D_POSIX_PTHREAD_SEMANTICS -I/usr/java/include -I/usr/java/include/
solaris -I/home1/users/biyer/Bala/OAPI/include -I/home1/users/biyer/
Bala/OAPI/src Common.cpp liba.a libb.b -o libSubscribe.so
Then i compiled my source as
CC -DSOLARIS -DSUN4 -DSUN -DSVR4 -D_POSIX_PTHREAD_SEMANTICS -I/home1/
users/biyer/Bala/OAPI/include -I/home1/users/biyer/Bala/OAPI/src
Main.cpp -o Main.o
Now when i run Main.o it says its not able to open the shared
library. It prints an error message which is part of my code.
"Error Loading the Dynamic Library"

This is really getting off topic, but what does dlerr() say?

Just a hunch, however: you need a -ldl at the end of your link
line. Otherwise, you just get stubs for dlopen et al. (I'll
admit that I don't understand this. By default, the system
libraries are loaded dynamically, so the guts of libdl must be
there, even if you don't specify it.)

Maybe the g++ driver adds this automatically. (I have it in my
Linux builds with g++, however. I don't know if it's necessary,
however. I know I needed it once, and I probably just threw it
in everywhere.)

--
James Kanze (GABI Software) email:[e-mail]
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

Haha. I tried that already but doesnt seem to work. I looked at
dlerror() and it says it couldnt find a referenced symbol. the name
of the symbol is mangled. And since the static libraries that i am
using are external, i dont have the source code to find out where and
how its declared. I just linked the static libraries while creating
the shared library using the above command. Not sure though which way
to go ahead :)

[James Kanze]

On Nov 13, 7:33 pm, Bala <[e-mail]:

On Nov 13, 4:56 am, James Kanze <[e-mail]:

On Nov 13, 12:02 am, Bala <[e-mail]:

On Nov 9, 5:01 am, James Kanze <[e-mail]:
On Nov 8, 8:50 pm, Bala <[e-mail]:

[...]
This is really getting off topic, but what does dlerr() say?

[...]

Haha. I tried that already but doesnt seem to work. I looked at
dlerror() and it says it couldnt find a referenced symbol.

After dlopen()?

the name of the symbol is mangled. And since the static
libraries that i am using are external, i dont have the source
code to find out where and how its declared.

nm libxxx.so | egrep symbol

can be useful in such cases. There is also c++filt, to
demangle. You might try demangling, and greping for the
demangled name in the libs. Just in case the symbol is actually
in C code, but the declaration you pulled in didn't have the
``extern "C"'' linkage specification.

Another possibility is that the library was compiled with a
different compiler, and so mangles differently. (Sun CC
supports at least two different conventions: see the -compat=4
option. Or one of the libraries was compiled with g++; this
would explain why there was no problem with g++.)

I just linked the static libraries while creating the shared
library using the above command. Not sure though which way to
go ahead :)

It sounds like you're in the Unix version of DLL-hell:-). The
worst thing about it is that if you get it to work on your
platform, it still might not work when deployed, because one of
the shared objects it depends on doesn't have the same version.
In my experience, you should make very, very sparing use of
shared objects, limiting their use to cases where it actually
has some necessary advantage.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]