|
Home > Archive > Unix Programming > April 2004 > Circular dependancy in shared object
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Circular dependancy in shared object
|
|
| Avi Uziel 2004-04-18, 1:33 pm |
| Hi All,
My environment is:
Solaris 8, with Sun WorkShop 6 update 2 C++ 5.3.
I'm writing a plugin for third party application. The plugin is a shared
object which the
third party application loads by using dlopen.
My plugin is using another third party shared object (libACE.so).
The problem is that when the plugin is loaded the ld fail to locate
libACE.so.
3rd party application -> dlopen my plugin -> use libACE.so
I tried LD_LIBRARY_PATH - the third party application ignore this env
variable.
I tried to compile my plugin so with -R and point to the libACE.so
location - is the -R path must be
absolute or can it be relative? if relative then to who - is it to my plugin
so or to the application
executable?
The only thing that work was compiling my plugin with -R and abselot path to
libACE.so - this is
not a good practice, since I can't know in compilation time the location of
libACE.so.
any suggestions?
Thanks
Avi
| |
| Fletcher Glenn 2004-04-18, 2:34 pm |
|
"Avi Uziel" <ouziel_a@hotmail.com> wrote in message
news:1085ei6o019aq94@corp.supernews.com...
> Hi All,
>
> My environment is:
> Solaris 8, with Sun WorkShop 6 update 2 C++ 5.3.
>
> I'm writing a plugin for third party application. The plugin is a shared
> object which the
> third party application loads by using dlopen.
>
> My plugin is using another third party shared object (libACE.so).
> The problem is that when the plugin is loaded the ld fail to locate
> libACE.so.
>
> 3rd party application -> dlopen my plugin -> use libACE.so
>
> I tried LD_LIBRARY_PATH - the third party application ignore this env
> variable.
> I tried to compile my plugin so with -R and point to the libACE.so
> location - is the -R path must be
> absolute or can it be relative? if relative then to who - is it to my
plugin
> so or to the application
> executable?
>
> The only thing that work was compiling my plugin with -R and abselot path
to
> libACE.so - this is
> not a good practice, since I can't know in compilation time the location
of
> libACE.so.
>
> any suggestions?
>
> Thanks
> Avi
>
LD_LIBRARY_PATH is only read during exec(). If you're setting it after you
have started your program, you're wasting your time. The way to get around
this is to check LD_LIBRARY_PATH, if it is not correct, then set it, and
then exec your program agian (without forking).
--
Fletcher Glenn
| |
| Frank Cusack 2004-04-18, 6:34 pm |
| On Sun, 18 Apr 2004 20:26:28 +0300 "Avi Uziel" <ouziel_a@hotmail.com> wrote:
> Hi All,
>
> My environment is:
> Solaris 8, with Sun WorkShop 6 update 2 C++ 5.3.
>
> I'm writing a plugin for third party application. The plugin is a shared
> object which the
> third party application loads by using dlopen.
>
> My plugin is using another third party shared object (libACE.so).
> The problem is that when the plugin is loaded the ld fail to locate
> libACE.so.
>
> 3rd party application -> dlopen my plugin -> use libACE.so
I think you've mischaracterized the problem; this dependency is not
circular.
> I tried LD_LIBRARY_PATH - the third party application ignore this env
> variable.
> I tried to compile my plugin so with -R and point to the libACE.so
> location - is the -R path must be
> absolute or can it be relative? if relative then to who - is it to my plugin
> so or to the application
> executable?
On Solaris, it can be relative to the application using $ORIGIN.
> The only thing that work was compiling my plugin with -R and abselot path to
> libACE.so - this is
> not a good practice, since I can't know in compilation time the location of
> libACE.so.
>
> any suggestions?
- Use a configuration file which specifies the absolute path to libACE.so,
and dlopen() the library yourself.
- Insist that libACE.so be installed in the same dir as your plugin (it
could simply be a symlink).
/fc
| |
| Avi Uziel 2004-04-19, 6:34 am |
| How do I use $ORIGIN ?
should it be a part of the -R flag?
Thanks,
Avi
"Frank Cusack" <fcusack@fcusack.com> wrote in message
news:m31xmleyio.fsf@magma.savecore.net...
> On Sun, 18 Apr 2004 20:26:28 +0300 "Avi Uziel" <ouziel_a@hotmail.com>
wrote:
>
> I think you've mischaracterized the problem; this dependency is not
> circular.
>
plugin[vbcol=seagreen]
>
> On Solaris, it can be relative to the application using $ORIGIN.
>
path to[vbcol=seagreen]
of[vbcol=seagreen]
>
> - Use a configuration file which specifies the absolute path to libACE.so,
> and dlopen() the library yourself.
> - Insist that libACE.so be installed in the same dir as your plugin (it
> could simply be a symlink).
>
> /fc
| |
| Casper H.S. Dik 2004-04-19, 8:34 am |
| "Avi Uziel" <ouziel_a@hotmail.com> writes:
>How do I use $ORIGIN ?
>should it be a part of the -R flag?
Yes, typically used as:
-R '$ORIGIN/../lib'
you need '' to prevent the shell from interpolating a
value for $ORIGIN; in makefiles you need to use $$ORIGIN because
make's variable expansion can only be prevented by doubling the $.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
|
|
|
|
|