guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Thread Plug-in Support #2


From: Marius Vollmer
Subject: Re: [PATCH] Thread Plug-in Support #2
Date: 13 Apr 2001 11:16:45 +0200
User-agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7

Rob Browning <address@hidden> writes:

> Marius Vollmer <address@hidden> writes:
> 
> > This is an important point.  We should be able to specify the versions
> > of dynamic libraries that we want to link.  "ltdl" should be the agent
> > that carries out the details.
> 
> OK.  Sounds good, though I don't know what the details might look
> like.  What are we likely to want to do for 1.6.0?

Hmm, nothing?  Specifying versions during dynamic-link is not
supported by the underlying (dlopen) machinery, so it is not obvious
what to do...

> > I don't think encoding the version information into the library name
> > is the best way to do it.  It might work on GNU/Linux, but it might
> > not work elsewhere.  Additionally, we must make sure that no conflicts
> > arise from linking incompatible versions.  For example, it wont
> > probably work to load both "somelib.so.5.3" and "somelib.so.4.9" into
> > the same process.  We should signal an error for this.
> 
> Good points.  Should the version be handled by the name, or should we
> make the libraries more self-describing -- i.e. each has a "version"
> function that reports its info.  (Probably not, but I figured while
> we're discussing the topic we ought to consider all the options.)

We should come up with something that doesn't only work for Guile.
Ideally, libtool should provide this versioning and we should just use
it.  I think it would be OK if advanced features like detailed
information about the loaded libraries will only work for .la files.

> > What would %dlib-path consist of?  Would it just be LD_LIBRARY_PATH,
> > or more?  `dynamic-link' already does path searching on its own.
> 
> Where does dynamic-link look?

It uses lt_dlopen directly, that is, it looks where lt_dlopen looks:
first, it tries to dlopen the file directly, using a number of
extensions, then it looks in a list of directories specified via
lt_dladdsearchdir etc, then in LD_LIBRARY_PATH (or other, depending on
the OS), then in LTDL_LIBRARY_PATH.  `dlopen' itself does some
searching as well, in places dependent on the OS.

Note that of the three tools that do library searching (the
compile-time linker, ld.so, and lt_dlopen), no two look in the same
places.  What a mess.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]