Re: dynamic-link and LD_LIBRARY_PATH

Re: dynamic-link and LD_LIBRARY_PATH

[Bill Gribble]

I'm sure rlb will pipe up on this, since we have been dealing with this
type of problem lots lately :(  My impression (which may be wrong) is
that you're probably not having the problem you think you're having.

The "File not found" error does NOT necessarily mean that the file was
not found.  What it means is that lt_dlopen was not able to find a file
that it could successfully open.  This means either that there's no
library named whatever you specified, OR all libraries with matching
names could not be dlopen'ed.  Libraries may be un-dlopenable if they
have unresolved external symbols. 

If you force a .so file to be opened, you must have already dlopened any
other shared libs that the .so needs symbols from or you will see a
"File not found" error.  

If you open the .la file instead of the .so, or better yet don't specify
any extension at all, you'll have a better chance of getting the libs
you need loaded automatically.  Assuming that the person who built the
library actually linked it against everything it needs.  

b.g.



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: dynamic-link and LD_LIBRARY_PATH

[Bill Gribble]

On Mon, 2001-12-17 at 13:29, Anthony W. Juckel wrote:
> > If you open the .la file instead of the .so, or better yet don't specify
> > any extension at all, you'll have a better chance of getting the libs
> > you need loaded automatically.  Assuming that the person who built the
> > library actually linked it against everything it needs.  
> > 
> > b.g.
> 
> So, the remaining questions is, how to get around this.  After doing an
> nm on the requisite shared library, I'm definitely seeing many undefined
> procedures, so how do I figure out which libraries are needed?  Is there
> any reason to not link a shared library against all of its required
> libraries?

Sometimes two shared libraries can have circular dependencies.  This is
not an ideal situation, and you want to break such cycles where you can,
but you may not be able to.  In many such cases, it can be difficult to
get the linker to do what you want, and it may be easier just to leave
the dependencies unexpressed.  

If there aren't any circular dependencies, I see no reason why a library
shouldn't have all of its dependencies expressed in the .la file.  Most
people seem not to think this is important, unfortunately.  In gnucash,
we recommend that the 'make check' suite for shared libraries include
the trivial check for dependency completeness, which is to compile the
program 

int main(int argc, char ** argv} { return 0; }

but to add 'my_new_library.la' to the link line.

There are several ways to find out about library dependencies, depending
on where you got the lib from.  These days many package authors provide
a foo-config type script which you can ask for the link-time
dependencies.  That may or may not be useful to you in an automatic
dependency finder, but at worst you can pick through the output by hand
and figure out what other libraries you need to dlopen before your
target library.

Good luck,
b.g.
 





_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: dynamic-link and LD_LIBRARY_PATH

[Rob Browning]

"Anthony W. Juckel" <awj@digitalgreen.com> writes:

>> If you force a .so file to be opened, you must have already dlopened any
>> other shared libs that the .so needs symbols from or you will see a
>> "File not found" error.  
>
> This does indeed seem to be the case.  Thank you very much.

The upcoming 1.6 has the error message fixed to give a better
indication of what guile was looking for when the link failed.
However, there's no way to get more precise info about exactly what
went wrong, without a redesign of the libtool ltdl interface to allow
it to return more than just a static error string.

Another thing that people should watch out for is that older
libtool/guile combinations were ok with (dynamic-link "libfoo.so"),
but this won't work anymore -- in most cases, you just need to change
the call to omit the extension (as Bill suggested), i.e. (dynamic-link
"libfoo").

Hope this helps.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user