symbol collision between 3rd party shared libraries

[king]

I have an application which links to a 3rd-party shared library(say a)
and dlopens another one(say b). And each of those 3rd party shared
libraries requires another shared library respectively(say c &d). I am
facing a problem that there is a symbol collision between the shared
libraries c & d which is causing problem for me

MyAPP------links----> a.so -----------requires----->c.so
|----------dlopens------>b.so---------requires------->d.so

c.so and d.so has symbol collision

Everything is a shared library and equivalent static library is
available only for d.so i.e., d.a. everything else is shared library.

The aplication is for Linux.

How can this problem be solved? Is there a way?

Please dont spam the mailing list with messages like, this is not the
list for this topic. I just want to make sure, the c language itself
does not provide any mechanism (like static keyword etc...) to aid in
solving this problem

 

[Walter Roberson]

I have an application which links to a 3rd-party shared library(say a)
and dlopens another one(say b).

Please dont spam the mailing list with messages like, this is not the
list for this topic. I just want to make sure, the c language itself
does not provide any mechanism (like static keyword etc...) to aid in
solving this problem

The C language doesn't know the slightest thing about shared
libraries, so of coruse it does not provide any mechanism to deal
with the problems in them. You need to talk to a newsgroup
more appropriate to the problem.

 

[jaysome]

I have an application which links to a 3rd-party shared library(say a)
and dlopens another one(say b). And each of those 3rd party shared
libraries requires another shared library respectively(say c &d). I am
facing a problem that there is a symbol collision between the shared
libraries c & d which is causing problem for me

MyAPP------links----> a.so -----------requires----->c.so
|----------dlopens------>b.so---------requires------->d.so

c.so and d.so has symbol collision

Everything is a shared library and equivalent static library is
available only for d.so i.e., d.a. everything else is shared library.

The aplication is for Linux.

How can this problem be solved? Is there a way?

Please dont spam the mailing list with messages like, this is not the
list for this topic. I just want to make sure, the c language itself
does not provide any mechanism (like static keyword etc...) to aid in
solving this problem

The C language itself does not provide any mechanism (like static
keyword etc...) to aid in solving this problem.

 

[CBFalconer]

The C language doesn't know the slightest thing about shared
libraries, so of coruse it does not provide any mechanism to deal
with the problems in them. You need to talk to a newsgroup
more appropriate to the problem.

However the shared library has nothing to do with the problem; it
applies equally to simply linking any compilation units. The
solution therefore involves either altering the offending names in
the source, or making their usage strictly local to the compilation
unit. In the latter case the word 'static' will be useful.

The better libraries use a (hopefully) unique prefix to all their
externally accessible routines or storage to ameliorate this
problem.

 

[Thad Smith]

I have an application which links to a 3rd-party shared library(say a)
and dlopens another one(say b). And each of those 3rd party shared
libraries requires another shared library respectively(say c &d). I am
facing a problem that there is a symbol collision between the shared
libraries c & d which is causing problem for me

MyAPP------links----> a.so -----------requires----->c.so
|----------dlopens------>b.so---------requires------->d.so

c.so and d.so has symbol collision

Everything is a shared library and equivalent static library is
available only for d.so i.e., d.a. everything else is shared library.

How can this problem be solved? Is there a way?

My thought would be to use a utility to change to names in an object
file. Something like:
replaceObjSymbol <collision> <newname> a.so anew.o

I imagine that the symbol would, in general, need to be qualified to a
particular usage type (entry point, segment name, common name, etc.).

That is not, if course, a feature of Standard C.