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

[Rob Browning]

Marius Vollmer <address@hidden> writes:

> > 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...

Well, what I meant was until NIIBE's recent patch (and my Debian
patches), we were just installing (for example):

  /usr/lib/libguile.so.9.0.0
  /usr/lib/libguilethreads.so.0.0.0
  /usr/lib/libguilereadline.so.0.0.0

We did this for guile 1.3 and guile 1.4, but in guile 1.4, for Debian,
as we discussed, I changed the build process to version these libs in
parallel with libguile, so on a debian system, we now have:

  /usr/lib/libguile.so.10.0.0
  /usr/lib/libguilethreads.so.10.0.0
  /usr/lib/libguilereadline.so.10.0.0

So my question is, what should I make 1.6.0 do?  My proposal is, for
now, to just bump libguilereadline and libguilethreads along with
libguile (though in the future, their versioning can, and perhaps
should, vary from libguile's).  The only case where I think it would
be OK to leave their versioning alone is if we know for sure that
guile 1.6.0's libguileqthreads and libguilereadline API's are, in
fact, binary compatible with those in 1.3 and 1.4.

So for 1.6.0, I propose (partially in order to avoid Debian problems,
given what I've already done there):

  /usr/lib/libguile.so.11.0.0
  /usr/lib/libguilethreads.so.11.0.0
  /usr/lib/libguilereadline.so.11.0.0

Any serious objections?

> 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.

Given this, I doubt we need a %dlib-path.  I just wanted to make sure
there was a way (similar to GUILE_LOAD_PATH/%load-path) that a user
could install their own modules (and .so files) that would override
the system ones.  So to override a module foo that needed a
libguilefoo.so, you could just specify:

  GUILE_LOAD_PATH=/path/to/foo/scm-files \
  LD_LIBRARY_PATH=/path/to/foo/libs/ \
    guile ...

and that should work well enough, so I guess we're fine on that front.
  
> 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.

Yep :<

-- 
Rob Browning <address@hidden> PGP=E80E0D04F521A094 532B97F5D64E3930