Re: 1.6.0 problems with libguilereadline-v-12 and fix

[rm]

On Wed, Sep 18, 2002 at 10:22:30PM -0500, Rob Browning wrote:
> address@hidden (Paul Jarc) writes:
> 
> > By "temporarily", I meant that the modification should be undone
> > after linking the library.  Would this problem still remain then?
> 
> Hmm, that's an interesting idea.  It might be shaky in the presence of
> threads, but I'm not sure that's something we're aiming to accomodate.
> It would also prevent users from controlling things via their normal
> envt, vars, but perhaps that's not critical either.  It's definitely
> better than what I had been thinking in that direction.

May i point at similar sugestions i posted a while ago ;-)
Libltdl does provide API calls to modify the search path at runtime.
Why don't we extend dynamic linking like this:

static void *
sysdep_dynl_link (const char *fname, const char *subr)
{
  lt_dlhandle  handle;
  const char  *orig_path;
  const char  *guile_libdir = SCM_PKGLIB_DIR "/lib"

  /* save original search path */
  orig_path = lt_dlgetsearchpath();

  /* modify for guile usage - 
   * NOTE: we might want to _prepend_ here instead of just adding,
   * this would require some string operations and a call to
   * 'lt_dlsetsearchpath()' instead the following ...
   */
  void lt_dladdsearchdir(guile_libdir);

  handle = lt_dlopenext (fname);
  if (NULL == handle)
    {
      SCM fn;
      SCM msg;

      fn = scm_makfrom0str (fname);
      msg = scm_makfrom0str (lt_dlerror ());
      scm_misc_error (subr, "file: ~S, message: ~S", scm_list_2 (fn, msg));
    }

  /* restore original search path */
  void lt_dlsetsearchpath(orig_path);
  return (void *) handle;
}

A few remarks  (even so i might repeat myself):

 - Multithreading: libltdl _does_ provide a mutex framework - iff we
   need threadsave dynamic linking we "just" need to implement the 
   mutex/locking code (BTW, i don't see where this is different from the
   current aproach - we need to have mutexes too [see the comment at the
   beginning of file 'dynl.c']).

 - Putting things in a standard place, or, like Marius phrased it:
   "The right thing is to configure your system so that the installed 
    libraries are visible to all programs, in the standard way."
   I can't agree here -- those standard places are meant for libraries
   that can and will be shared by many different applications. Object
   code like guilereadline.so isn't meant to be of any use to non-guile
   applications (and in the few cases an application really needs to
   dynamiclly link against such objects we should assume that the programmer
   knew what she is doing and expect her to add our guile specific library
   location(s) to the search path). I think one can reduce this discussion
   to the question: "what's the true nature of code linked dynamically 
   from guile - is it a normal shared library or is it rather a 'plug-in'
   meant to extend an application?" I tend to favour the second view.
   Looking at other interpreters (shudder): both perl and python (as 
   well as some more esotheric languages) have their "private" library
   space.

> However, I guess at the moment, since we have the issue documented in
> the INSTALL file, I'm tempted to leave things alone until we can
> hopefully figure out a more general solution (during the 1.7
> development cycle), and then only change things once.

I don't really see what the solution i suggested would break that
wouldn't break with the solution mentioned in the INSTALL file. 
Modifying the environment will affect the linking behaviour of the
application as a whole _and_ will change the linking behaviour of all
child processes -- not really an option for many uses.

> Marius has suggested that perhaps the right thing to do is discuss
> this with the libltdl people and see if we can settle on a more
> general solution, one that might also involve a versioned lt_dlopen.
> I'm inclined in that direction as well.

Yes, i think this is a good idea (and, given the number of problem reports
in this list alone, probably needs to be done soon).

  Ralf Mattes