guile-user
[Top][All Lists]
Advanced

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

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


From: Greg Troxel
Subject: Re: 1.6.0 problems with libguilereadline-v-12 and fix
Date: 20 Sep 2002 08:04:22 -0400

I admit to not understanding the debian -rpath rules.  Presumably that
is intended to allow a package to be installed for a different prefix
than the one it was built for.  But guile won't work that way, since
it needs to find ice-9/foo.scm.

Your point about apps needing to link with the srfi libs is one I had
not considered.  If they link at compile time, then one either has
them in a default path, uses LD_LIBRARY_PATH, or uses -rpath/-R  (or
loses).  This is exactly the situation for libguile today.

I think my real points are

1) There is an important class of systems and reasonable user behavior
   (BSD with odd prefixes, at least) where guile works fine except for
   the dlopening of guile's internal support libraries.

2) It is always the right thing for guile to open the library in
   exactly the installed path.  (If not, scheme files like ice-9/foo
   should be searched for in the same way - it makes no sense to do
   these differently, and without a complete solution you can't unpack
   a built guile someplace else.)

2a) I don't think it is important to support having a package be at a
   prefix other than where it was built.   (But I don't understand the
   debian rationale, and I agree that it usually makes sense.)

3) Opening the library in the installed path is an easy fix.

4) People will think guile is lame if they have to set LD_LIBRARY_PATH
   just for guile.  (I don't - I just think it has a bug that needs
   fixing....)


I really don't understand why people think it is a good idea for guile
to go searching in the default list of library places for
libguilereadline-v-12.so.  The only justification I have heard is that
this is the default behavior of dlopen, and that shared libraries tend
to work that way.

It would be instructive to look at gimp and plugins (these files are
really plugins, not 'shared libraries', although that's a fine
distinction):

  /usr/X11R6/libexec/gimp/1.1/modules:
  total 71
  -rwxr-xr-x  1 root  wheel  10468 Nov 16  2000 libcdisplay_gamma.so
  -rwxr-xr-x  1 root  wheel  10604 Nov 16  2000 libcdisplay_highcontrast.so
  -rwxr-xr-x  1 root  wheel   7492 Nov 16  2000 libcolorsel_gtk.so
  -rwxr-xr-x  1 root  wheel  20825 Nov 16  2000 libcolorsel_triangle.so
  -rwxr-xr-x  1 root  wheel  20377 Nov 16  2000 libcolorsel_water.so

  /usr/X11R6/libexec/gimp/1.1/plug-ins:
  total 5281
  -r-xr-xr-x  1 root  wheel   33504 Nov 16  2000 AlienMap
  -r-xr-xr-x  1 root  wheel   35488 Nov 16  2000 AlienMap2
  [rest omitted]

I'm not really clear how gimp links plugins, but I definitely don't
have to set LD_LIBRARY_PATH.  gimp seems to put the module path in the
search path, since it looks for various libraries that aren't modules
there (from a ktrace).  But modules are definitely looked for in the
'right' place first.

Maybe this is a sign that libguilereadline really should be in
$(prefix)/libexec/guile
rather than in $(lib).  But that's a much longer and less useful
debate...




        Greg Troxel <address@hidden>




reply via email to

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