OK, I believe you know. :) I either read the dlopen man page
incorrectly, or the dlopen mane page is incorrect.
Thanks...
Tom
On Thu, 21 Dec 2000, Bjoern Fischer wrote:
> > once at process startup, and from a runpath setting within
> > the object from which the call to dlopen() or
> once at process startup, and from a runpath setting within
> the object from which the call to dlopen() originated. These
> search rules will only be applied to path names that do not
> contain an embedded '/'. Objects whose names resolve to
[...]
> ... and from a
On Wed, Dec 20, 2000 at 05:09:48PM -0600, Tim Mooney wrote:
> In regard to: Re: dlopen on Solaris compared with IRIX/Tru64, Albert...:
>
> >Not all systems allow you to embed RPATH in a library. Tru64 UNIX 4.0D
> >is one. I think libtool 1.4 and above allow you to embed RP
In regard to: Re: dlopen on Solaris compared with IRIX/Tru64, Albert...:
>Not all systems allow you to embed RPATH in a library. Tru64 UNIX 4.0D
>is one. I think libtool 1.4 and above allow you to embed RPATH.
Unless I misunderstand you, that's not correct:
05:04pm obelisk lib$odum
I am not so sure about this. From the man page for dlopen():
If other objects were link-edited with pathname when path-
name was built, that is, the pathname has dependencies on
other objects, those objects will automatically be loaded by
dlopen(). The directory search p
On Wed, Dec 20, 2000 at 09:53:42PM +0100, Bjoern Fischer wrote:
> > BTW, I posted the same message to comp.unix.solaris and it turns out
> > there is a solution. In my code below, I dlopen libz.so and then
> > libpng.so. This fails. libpng.so has a hard-coded dependency on
> > libz.so.2. So, if I
On Wed, Dec 20, 2000 at 01:54:04PM -0600, Albert Chin-A-Young wrote:
> On Wed, Dec 20, 2000 at 02:01:17PM -0500, Tom Kacvinsky wrote:
> > Huh? My experience (on Solaris) has been that if foo.so has an
> > embedded RPATH and the application bar uses foo.so and also has a
> > RPATH, then the binary
> BTW, I posted the same message to comp.unix.solaris and it turns out
> there is a solution. In my code below, I dlopen libz.so and then
> libpng.so. This fails. libpng.so has a hard-coded dependency on
> libz.so.2. So, if I dlopen libz.so.2 and then libpng.so, everything
> works! Now, I don't th
On Wed, Dec 20, 2000 at 02:01:17PM -0500, Tom Kacvinsky wrote:
> Huh? My experience (on Solaris) has been that if foo.so has an embedded RPATH
> and the application bar uses foo.so and also has a RPATH, then the binary's
> RPATH is used for shared lib lookups. If the RPATH of the binary does not
On Wed, Dec 20, 2000 at 02:01:17PM -0500, Tom Kacvinsky wrote:
> Huh? My experience (on Solaris) has been that if foo.so has an
> embedded RPATH and the application bar uses foo.so and also has a
> RPATH, then the binary's RPATH is used for shared lib lookups. If
> the RPATH of the binary does n
Huh? My experience (on Solaris) has been that if foo.so has an embedded RPATH
and the application bar uses foo.so and also has a RPATH, then the binary's
RPATH is used for shared lib lookups. If the RPATH of the binary does not
include the paths in the shared lib's RPATH, then the shared lib's d
Hello Albert,
> dependent on nothing:
> $ ldd libpng.so
> libz.so.2 => (file not found)
This is your problem. Your libpng.so is not self-contained.
The run-time linker is not able to resolve all dependencies
of your libpng.so. You may set LD_LIBRARY_PATH, but you
definetly want to fix yo
This is not a libtool-specific question but has some relation to ltdl.
I'm trying to dlopen two libraries without compiling with -R or
running the executable with LD_LIBRARY_PATH set. The libraries are
libpng.so and libz.so. libpng.so is dependent on libz.so. libz.so is
dependent on nothing:
$
13 matches
Mail list logo
