This is the mail archive of the guile@cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: C modules and shared libraries


On Thu, Jun 03, 1999 at 02:48:49PM +0100, Ian Grant wrote:
> 
> For a while it looked like we could rely on libtool getting the
> inter-library dependencies right, but they've dropped that, AFAIK.

No, we didn't drop it!  It just that the deplib stuff perturbs *a lot*
of the code in libtool, and we had a lot of smaller changes that needed
to be released in the short term.

The current situation is that the 1.3 releases are being made from a
1.3 branch which was created just before the deplib code was merged
into the trunk.  The code in the trunk will soon be released as
libtool-1.4 (a few weeks I expect) and is broadly working on most
platforms already as far as we are aware.

> The only alternative is to use explicit calls to dlopen to load the
> required libraries before loading the module.
> 
> The dlopen interface in libguile is not suitable for this because it makes
> rather strong assumptions about where modules are to be found, and it
> passes the wrong flags to dlopen on some systems (eg. linux), so cannot be
> used to pre-load dependent libraries.

The recent 1.3 releases of libtool and the forthcoming 1.4 release
include libltdl (LibTool Dynamic Loading) which provides new
functionality to support portable dynamic loading of modules in C
(including simulation of dlopening on platforms with no shared library
support).  I would recommend looking at porting the guile module
backend to use libltdl for portability reasons...  there has also been
talk of incorporating support for an enhanced version of Gord
(Matzigkeit)'s libdld library into libltdl so that it would be
possible to apply the abstract lt_dlopen/lt_dlsym/lt_dlclose interface
on *any* platform (including static archive only hosts) and have
libraries linked into the running executable (not simulated as is the
case with the current implementation).

Now is the time to play with all this code to iron out any creases
before the 1.4 release proper....

> There are two, no three!, other dlopen interfaces. One is that shipped
> with guile-gtk. The other is libltdl, which is shipped with libtool >1.3. 
> The third is a stripped-down version of the guile-gtk dlopenhelper which
> Russ McManus uses for his Sybase library. 
> 
> Unfortunately, none of these interfaces are capable of resolving
> references recursively, which is what we require for the module system.

libltdl should handle recursive loading properly, because one
lt_dlopen()s the libtool generated .la file which knows all the
dependencies (in the CVS trunk with deplib code).

> For example: the module I'm working on for Postgres requires an interface
> library lipq.so, that comes with Postgres. On a glibc2 system, libpq.so
> itself requires libcrypt.so to be loaded. This if my Postgres module is to
> be loaded via dlopen then first libcrypt must be loaded, followed by
> libpq, followed by the actual Postgres interface module. However if it's
> built for a libc5 system, say, then libcrypt.so doesn't exist and isn't
> needed.
> 
> The dynamic loader must somehow find out which libraries a given module
> depends upon and load them all first, in the correct order. This isn't
> necessarily that difficult: at configure time we know what dependencies
> there are (we find them from the xxx-config scripts etc.), so we should be
> able to put this list into a text file in some known place. When the
> module system loads the module it should first find the text file and load
> the dependencies, then load the module.

It lloks like you have an ideal application to put the libtool 1.4
prerelease code through its paces =)O|

> This is not really something that is specific to guile. What do people
> think? 

Agreed.

> Should we really be implementing this much low-level functionality
> in guile?

No.

> A system like this is necessary for any language/program that
> needs a dynamic library loader. There is GNU dld, but it doesn't support
> modern binaries and there's not been a new release since 1996. Is anyone
> likely to resurrect dld soon?

Maybe.... see my earlier comments.

Cheers,
	Gary.
-- 
  ___              _   ___   __              _  email:gary@oranda.demon.co.uk
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___       gary@gnu.org 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/                      /___/                pgp-2 public key:
http://www.oranda.demon.co.uk               http://www.oranda.demon.co.uk/pgp


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]