* Re: dynamic-link and LD_LIBRARY_PATH
[not found] ` <1008617386.16363.1.camel@alienway>
@ 2002-04-02 13:57 ` Bill Gribble
2002-04-10 20:10 ` Rob Browning
1 sibling, 0 replies; 3+ messages in thread
From: Bill Gribble @ 2002-04-02 13:57 UTC (permalink / raw)
Cc: Martin Grabmueller, guile-user
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
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: dynamic-link and LD_LIBRARY_PATH
[not found] ` <1008617386.16363.1.camel@alienway>
2002-04-02 13:57 ` Bill Gribble
@ 2002-04-10 20:10 ` Rob Browning
1 sibling, 0 replies; 3+ messages in thread
From: Rob Browning @ 2002-04-10 20:10 UTC (permalink / raw)
Cc: Bill Gribble, Martin Grabmueller, guile-user
"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
^ permalink raw reply [flat|nested] 3+ messages in thread