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

[ Post a follow-up to this message ]

"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

[ Post a follow-up to this message ]

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 plug
in
> 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 o
f
> 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

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

"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.

[ Post a follow-up to this message ]