1.6.0 problems with libguilereadline-v-12 and fix

1.6.0 problems with libguilereadline-v-12 and fix

[Greg Troxel]

I built 1.6.0 on FreeBSD/i386 4.6-ish (tracking stable) with
--prefix=/usr/foo
I have (use-modules (ice-9 readline)) in my .guile, and guile failed
on startup trying to dynlink libguilereadline-v-12.
It seems that dynamic-link only looks in standard places.

For reasons I do not understand, guile/readline with the same /usr/foo
works on NetBSD 1.5.4_ALPHA/i386, even without the below patch.  It
finds /usr/foo/lib/libguilereadline-v-12, but it seems incorrect of
libtool to look there.

This seems broken in two ways:

  guile should look for its own libraries in exactly one place, the
  location where it was installed.

  guile should certainly look in $(prefix)/lib

So, I modified guile-readline/readline.scm to look in the right place
(although perhaps not only in the right place).

Perhaps a new procedure that is like dynamic link, but only looks in
the installed prefix, is in order, for internal use?
I suspect this problem affects the srfi code.

For you hard-core regression testers, perhaps testing with a
non-standard prefix is in order.  For extra points, put defective
versions of the libs in /usr/local or some other 'normal' place.

Index: readline.scm
===================================================================
RCS file: /QUIST-CVS/guile/guile-readline/readline.scm,v
retrieving revision 1.1.1.2
retrieving revision 1.2
diff -u -r1.1.1.2 -r1.2
--- readline.scm	2002/07/19 17:56:31	1.1.1.2
+++ readline.scm	2002/09/18 20:19:17	1.2
@@ -36,7 +36,11 @@
 
 (if (not (feature? 'readline))
     (dynamic-call "scm_init_readline"
-                  (dynamic-link "libguilereadline-v-12")))
+                  (dynamic-link 
+		   (string-append
+		    (assq-ref %guile-build-info 'libdir)
+		    "/"
+		    "libguilereadline-v-12"))))
 
 (if (not (feature? 'readline))
     (scm-error 'misc-error


On NetBSD, guile mysteriously looks in the right place:

  9315 guile    CALL  open(0x8102280,0,0x1b6)
  9315 guile    NAMI  "/usr/lib/libguilereadline-v-12.la"
  9315 guile    RET   open -1 errno 2 No such file or directory
  9315 guile    CALL  open(0x80a2dc0,0,0x1b6)
  9315 guile    NAMI  "libguilereadline-v-12.la"
  9315 guile    RET   open -1 errno 2 No such file or directory
  9315 guile    CALL  open(0x48059080,0,0x48052d20)
  9315 guile    NAMI  "/usr/lib/libguilereadline-v-12.so"
  9315 guile    RET   open -1 errno 2 No such file or directory
  9315 guile    CALL  __stat13(0x48059100,0xbfbfce70)
  9315 guile    NAMI  "/usr/foo/lib/libguilereadline-v-12.so"
  9315 guile    RET   __stat13 0
  9315 guile    CALL  open(0x48059100,0,0x48052d20)
  9315 guile    NAMI  "/usr/foo/lib/libguilereadline-v-12.so"
  9315 guile    RET   open 5
  9315 guile    CALL  read(0x5,0xbfbfce3c,0x34)

env|grep foo turns up only /usr/foo/bin in PATH and /usr/foo/man in
MANPATH.
It can't be from PATH, since other dirs in PATH like /usr/gnats/bin
come first and /usr/gnats/lib is not tried.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Marius Vollmer]

Greg Troxel <gdt@ir.bbn.com> writes:

> This seems broken in two ways:
> 
>   guile should look for its own libraries in exactly one place, the
>   location where it was installed.
> 
>   guile should certainly look in $(prefix)/lib

I don't agree.  While your suggestions would make it work, they would
do so with non-standard means.  The right thing is to configure your
system so that the installed libraries are visible to all programs, in
the standard way.

Your suggestions work against the usual means of managing shared
libraries, not with them.  I think we should work with them, even if
they are slightly broken.

So, in my view, the right fix is to set LD_LIBRARY_PATH or
LTDL_LIBRARY_PATH.

It would also be acceptable to change Guile to also look into the
directories from /etc/ld.so.conf on GNU/Linux, and generally to follow
the behavior of dlopen as closely as possible.  (One should also fix
ld to be consistent with ld.so.)

> So, I modified guile-readline/readline.scm to look in the right place
> (although perhaps not only in the right place).

Instead, you should configure the whole system to look into the right
places.

> On NetBSD, guile mysteriously looks in the right place:
> [...] 
>   9315 guile    CALL  open(0x48059100,0,0x48052d20)
>   9315 guile    NAMI  "/usr/foo/lib/libguilereadline-v-12.so"
>   9315 guile    RET   open 5
>   9315 guile    CALL  read(0x5,0xbfbfce3c,0x34)

The ".so" files are opened by dlopen, I think, not by ltdl_dlopen.
Does the documentation of dlopen reveal where it looks?

> env|grep foo turns up only /usr/foo/bin in PATH and /usr/foo/man in
> MANPATH.

Since you already include /usr/foo in PATH and MANPATH, why not also
put it into LD_LIBRARY_PATH?

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Paul Jarc]

Marius Vollmer <mvo@zagadka.ping.de> wrote:
> Greg Troxel <gdt@ir.bbn.com> writes:
>> This seems broken in two ways:
>>
>>   guile should look for its own libraries in exactly one place, the
>>   location where it was installed.
>>
>>   guile should certainly look in $(prefix)/lib
>
> I don't agree.  While your suggestions would make it work, they would
> do so with non-standard means.

Are there standard means to do the same thing?  I have the same
problem.

> The right thing is to configure your system so that the installed
> libraries are visible to all programs, in the standard way.

I disagree about the word "right".  It's the traditional thing, and
apparently the expected thing, but it would be nice if it weren't the
only thing.

> Your suggestions work against the usual means of managing shared
> libraries, not with them.  I think we should work with them, even if
> they are slightly broken.

I think we should fix them.

But how about this: when linking one of Guile's own libraries,
temoporarily prepend (assq-ref %guile-build-info 'libdir) to
LD_LIBRARY_PATH or LTDL_LIBRARY_PATH, whichever is searched first.
Would that satisfy everyone?

> Instead, you should configure the whole system to look into the right
> places.

On my system, each installation of each version of each package gets
its own unique installation prefix.  I configure each package to find
the libraries it needs at compile time; LD_LIBRARY_PATH would be
awfully big if I didn't.  But many packages don't need to be told
specifically to check PREFIX/lib; they look there automatically.  Most
of the others can be told to look there by adding
-Wl,-rpath,PREFIX/lib to LDFLAGS, which is easy enough for me.  But
even that doesn't work for Guile.


paul


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Rob Browning]

prj@po.cwru.edu (Paul Jarc) writes:

> But how about this: when linking one of Guile's own libraries,
> temoporarily prepend (assq-ref %guile-build-info 'libdir) to
> LD_LIBRARY_PATH or LTDL_LIBRARY_PATH, whichever is searched first.
> Would that satisfy everyone?

I believe the problem is that if we start modifying either
LD_LIBRARY_PATH or LTDL_LIBRARY_PATH (or the attendant libltdl
functions), we won't just affect guile, we'll affect any app linked
against libguile (if we perform the modification in libguile) or any
other library we load that also uses libltdl or dlopen.  If other
libraries or apps also decide to modify LD_LIBRARY_PATH,
LTDL_LIBRARY_PATH, etc., the result wrt shadowing become order
dependent and hard to predict.

Maybe we don't care about that, but I believe that's the major
concern.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Paul Jarc]

Rob Browning <rlb@defaultvalue.org> wrote:
> prj@po.cwru.edu (Paul Jarc) writes:
>> But how about this: when linking one of Guile's own libraries,
>> temoporarily prepend (assq-ref %guile-build-info 'libdir) to
>> LD_LIBRARY_PATH or LTDL_LIBRARY_PATH, whichever is searched first.
>> Would that satisfy everyone?
>
> I believe the problem is that if we start modifying either
> LD_LIBRARY_PATH or LTDL_LIBRARY_PATH (or the attendant libltdl
> functions), we won't just affect guile, we'll affect any app linked
> against libguile (if we perform the modification in libguile) or any
> other library we load that also uses libltdl or dlopen.

By "temporarily", I meant that the modification should be undone after
linking the library.  Would this problem still remain then?


paul


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Rob Browning]

prj@po.cwru.edu (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.

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.

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.

Thanks

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Robert Uhl <ruhl@4dv.net>]

Rob Browning <rlb@defaultvalue.org> writes:
>
> It would also prevent users from controlling things via their normal
> envt, vars, but perhaps that's not critical either.

As the sort who normally manages things through environment variables,
I'm not certain I like this idea...

-- 
Robert Uhl <ruhl@4dv.net>
You see, in the post-televisual world we read.  --John Gipson


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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:
> prj@po.cwru.edu (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


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Rob Browning]

rm@fabula.de writes:

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

That has the same fundamental problem as setting LD*_LIBRARY_PATH
unless we only modify the value briefly, and *every* time we call
lt_dlopen (still an interesting suggestion).

The problem is that other libraries (or the app linking against
libguile itself) may also put their directories in there, and if, for
example, even one of them puts "/usr/local/lib" at the front after
you've made your modifications, and if there's another "incorrect"
version of some part of guile in /usr/local/lib, then you're likely to
be in trouble the next time you call lt_dlopen.

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

But libguilereadline is the *only* library for which this isn't the
case.  The rest are publically available and it apps are expected to
link directly against them. 

>    "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?"

As it stands now, the answer is "both".  That's one of the main
reasons this problem is hard.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Paul Jarc]

Rob Browning <rlb@defaultvalue.org> wrote:
> rm@fabula.de writes:
>> 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:
>
> That has the same fundamental problem as setting LD*_LIBRARY_PATH
> unless we only modify the value briefly, and *every* time we call
> lt_dlopen (still an interesting suggestion).

That's what Ralf's code does, IIUC.

> The rest are publically available and it apps are expected to link
> directly against them.

For the ones that use ld.so to do their linking, they can already be
configured to find the libraries with -rpath.  For the ones that use
libltdl, the most general fix would be to make libltdl search the same
places that ld.so would; then -rpath will work for them too.


paul


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[rm]

On Thu, Sep 19, 2002 at 10:02:25AM -0500, Rob Browning wrote:
> rm@fabula.de writes:
> 
> > 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:
> 
> That has the same fundamental problem as setting LD*_LIBRARY_PATH
> unless we only modify the value briefly, and *every* time we call
> lt_dlopen (still an interesting suggestion).
> The problem is that other libraries (or the app linking against
> libguile itself) may also put their directories in there, and if, for
> example, even one of them puts "/usr/local/lib" at the front after
> you've made your modifications, and if there's another "incorrect"
> version of some part of guile in /usr/local/lib, then you're likely to
> be in trouble the next time you call lt_dlopen.

Yes, that's true, but i consider this a problem on a higher level: there
_is_ a semantic to the order of places in the search path and guile can't
make decisions about that. 

> >  - 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.
> 
> But libguilereadline is the *only* library for which this isn't the
> case.  The rest are publically available and it apps are expected to
> link directly against them. 

Hmm, maybe we need a clearer/cleaner distinction between extensions and
libraries that other apps are supposed to link against? The code i've written
so far always was meant to extend guile or the guile interpreter embedded in
an application. I can't really see why any application needs to link against
libguilelibxml2.so or libguilegtk-1.2.so.0.

> >    "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?"
> 
> As it stands now, the answer is "both".  That's one of the main
> reasons this problem is hard.

For me that sounds like a good reason for making these two things separate
issues by using different code.

 Thanks for all the feedback

   Ralf


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Rob Browning]

rm@fabula.de writes:

>> As it stands now, the answer is "both".  That's one of the main
>> reasons this problem is hard.
>
> For me that sounds like a good reason for making these two things separate
> issues by using different code.

Hmm.  Which two things?  The canonical example I tend to think of is
srfi-4.  libguile-srfi-srfi-4 is intended to be used both by
(use-modules (srfi srfi-4)) *and* by any app that needs to do things
like scm_make_u8vector

>  Thanks for all the feedback

np.  This is something we definitely need to work out, though I'd be
happiest if we can work out a solution that fixes the problem at the
lowest, most-helpful level.  i.e. It would be really nice if we came
up with a solution that could be used by others as well...

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Marius Vollmer]

rm@fabula.de writes:

> I can't really see why any application needs to link against
> libguilelibxml2.so or libguilegtk-1.2.so.0.

libguilegtk-1.2 is a good example, actually.  It does not only provide
Scheme bindings to the Gtk+ toolkit, it also provides the fundamental
machinery for binding GtkObjects in general.  Thus, it is directly
linked into libguilegnome and other libraries that provide glue for
things that are based upon GtkObject but are not included in the basic
Gtk+ package.

Making a distinction between 'normal' shared libraries and 'plugin'
libraries only complicates things.  Still, you are free to turn your
extensions into plugins and pass a absolute file name to
'dynamic-link'.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Marius Vollmer]

rm@fabula.de writes:

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

When we can offer our libraries to "many different" applications, why
shouldn't we do it?  Guile is not foremost an application, it _is_ a
library that is meant to be used by many different applications.  It's
'extensions' (like libguilereadline, libguile-srfi-* or libguilegtk)
are in the same category.

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

It is a normal shared library.

I frankly don't see any problem with that except that people seem to
insist on installing Guile in non-standard places but refuse to
configure their system to recognize these non-standard places.

(An additional problem that unfortunately obscures the situation is
that libltdl is somewhat buggy and doesn't yet completely implement
what we want from it.  I hope that once this is fixed, the picture as
I see it will be clearer to others as well.)

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

Why not?  Are you afraid that the presence of the Guile libraries in
the search path will harm other code?

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

We will 'fork' libltdl for Guile and fix it for our use.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Paul Jarc]

Marius Vollmer <mvo@zagadka.ping.de> wrote:
> We will 'fork' libltdl for Guile and fix it for our use.

You'll offer your changes upstream, I hope?  Other packages may suffer
from the same problem.


paul


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Marius Vollmer]

prj@po.cwru.edu (Paul Jarc) writes:

> Marius Vollmer <mvo@zagadka.ping.de> wrote:
> > We will 'fork' libltdl for Guile and fix it for our use.
> 
> You'll offer your changes upstream, I hope?  Other packages may suffer
> from the same problem.

Yes, of course.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[tomas]

On Thu, Oct 03, 2002 at 05:56:13PM +0200, Marius Vollmer wrote:
> rm@fabula.de writes:
> 
> >  - Putting things in a standard place [...]
> >    I can't agree here -- those standard places are meant for libraries
> >    that can and will be shared by many different applications.
> 
> When we can offer our libraries to "many different" applications, why
> shouldn't we do it?  Guile is not foremost an application, it _is_ a
> library that is meant to be used by many different applications.  It's
> 'extensions' (like libguilereadline, libguile-srfi-* or libguilegtk)
> are in the same category.

[...]

Still, I think there are libs which make sense without Guile and some
which don't (the libguile-srfi* bunch comes to mind). Putting (or at
least having the possibility to put) those in a place ``out of the
way'' reduces clutter and seems to me good practice.

> Why not?  Are you afraid that the presence of the Guile libraries in
> the search path will harm other code?

The problem comes again when running `monster apps' like Apache, which
have tons of little plugins. Imagine all of the libraries have ideas
of their own about how $LD_LIBRARY_PATH should like. No, I think rather
$LD_LIBRARY_PATH to be something you use in pre-install test scripts
and as a desperate last resort.

[...]

> We will 'fork' libltdl for Guile and fix it for our use.

Hopefully the libltdl people catch up ;-)

Regards
-- tomas


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Marius Vollmer]

tomas@fabula.de writes:

> > Why not?  Are you afraid that the presence of the Guile libraries in
> > the search path will harm other code?
> 
> The problem comes again when running `monster apps' like Apache, which
> have tons of little plugins. Imagine all of the libraries have ideas
> of their own about how $LD_LIBRARY_PATH should like.

They wont all have their own ideas.  When they are all in one place,
there is only one additional directory to add to LD_LIBRARY_PATH.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[rm]

On Fri, Oct 04, 2002 at 02:04:40PM +0200, Marius Vollmer wrote:
> tomas@fabula.de writes:
> 
> > > Why not?  Are you afraid that the presence of the Guile libraries in
> > > the search path will harm other code?
> > 
> > The problem comes again when running `monster apps' like Apache, which
> > have tons of little plugins. Imagine all of the libraries have ideas
> > of their own about how $LD_LIBRARY_PATH should like.
> 
> They wont all have their own ideas.  When they are all in one place,
> there is only one additional directory to add to LD_LIBRARY_PATH.


Not really -- let's teke the Apache example: mod_guile won't be the only
module to modify LD_LIBRARY_PATH, there's mod_perl and mod_python and
mod_haskell ... Oh, and if you start to modify LD_LIBRARY_PATH from within
Apache, any app forking of the server will run with that modified path
as well (any CGI script, any interpreter started by that script etc.).
Definitely _not_ fun to debug. 

 Ralf 

> -- 
> GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405
> 
> 
> _______________________________________________
> Guile-user mailing list
> Guile-user@gnu.org
> http://mail.gnu.org/mailman/listinfo/guile-user


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Marius Vollmer]

rm@fabula.de writes:

> On Fri, Oct 04, 2002 at 02:04:40PM +0200, Marius Vollmer wrote:
> > tomas@fabula.de writes:
> > 
> > > > Why not?  Are you afraid that the presence of the Guile libraries in
> > > > the search path will harm other code?
> > > 
> > > The problem comes again when running `monster apps' like Apache, which
> > > have tons of little plugins. Imagine all of the libraries have ideas
> > > of their own about how $LD_LIBRARY_PATH should like.
> > 
> > They wont all have their own ideas.  When they are all in one place,
> > there is only one additional directory to add to LD_LIBRARY_PATH.
> 
> Not really -- let's teke the Apache example: mod_guile won't be the only
> module to modify LD_LIBRARY_PATH, there's mod_perl and mod_python and
> mod_haskell ... Oh, and if you start to modify LD_LIBRARY_PATH from within
> Apache, any app forking of the server will run with that modified path
> as well (any CGI script, any interpreter started by that script etc.).
> Definitely _not_ fun to debug. 

You would set LD_LIBRARY_PATH outside of Apache, system-wide.  When
Perl and Python require another directory to be in the path, they,
too, should make you include this directory in LD_LIBRARY_PATH
system-wide.  In my experience, such a setup is actually easier to
debug than one where individual applications or libraries each have
their own idea of where to look for 'modules'.

Instead of LD_LIBRARY_PATH, a better place might be /etc/ld.so.conf or
equivalent.

I would agree that traditional Unix is generally bad at keeping each
package into its own private location.  Instead of puuting all files
of the foo package into /package/foo, say, the traditional thing is to
put all libraries of all packages into /lib or its appendices /usr/lib
and /usr/local/lib.  Libraries are not identified with a hierachical
name, they are identified with their base name only.  The system
doesn't really distinguish between /lib/libbar.so and
/usr/lib/libbar.so.

This is not the optimal situation, and a more flexible naming scheme
for libraries is maybe needed, but I don't think we should develop
such a thing for Guile's private amusement.

I'm all for experimenting, and we should take care that people can
easily experiment on a higher-level using Guile's lower-level support.
Thus, it should be definitely possible to pass absolute file names to
dynamic-link and load-extension such that people can implement their
own searching algorithms, for example.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Dale P. Smith]

On 08 Oct 2002 23:16:56 +0200
Marius Vollmer <mvo@zagadka.ping.de> wrote:

> You would set LD_LIBRARY_PATH outside of Apache, system-wide.  When
> Perl and Python require another directory to be in the path, they,
> too, should make you include this directory in LD_LIBRARY_PATH
> system-wide.  In my experience, such a setup is actually easier to
> debug than one where individual applications or libraries each have
> their own idea of where to look for 'modules'.
> 
> Instead of LD_LIBRARY_PATH, a better place might be /etc/ld.so.conf or
> equivalent.

Oh please please please!

;^)

-Dale

-- 
Dale P. Smith
Senior Systems Consultant,      | Treasurer,
Altus Technologies Corporation  | Cleveland Linux Users Group
dsmith@altustech.com            | http://cleveland.lug.net
440-746-9000 x339               |


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[tomas]

On Tue, Oct 08, 2002 at 11:16:56PM +0200, Marius Vollmer wrote:
> rm@fabula.de writes:
> 

[about LD_LIBRARY_PATH]

> > Not really -- let's teke the Apache example: mod_guile won't be the only
> > module to modify LD_LIBRARY_PATH, there's mod_perl and mod_python and
> > mod_haskell ... Oh, and if you start to modify LD_LIBRARY_PATH from within
> > Apache, any app forking of the server will run with that modified path
> > as well (any CGI script, any interpreter started by that script etc.).
> > Definitely _not_ fun to debug. 
> 
> You would set LD_LIBRARY_PATH outside of Apache, system-wide.

Ick... In the system start scripts (e.g. /etc/init.d/apache for
GNU/Linux). So if you include a new module in Apache (to stay
with this example) you have to remember to edit the start script
in addition to the Apache conf file. On top of that you have to
wrestle with your distro's own ideas about start scripts :-(

>                                                                When
> Perl and Python require another directory to be in the path,

They manage not to.

>                                                              they,
> too, should make you include this directory in LD_LIBRARY_PATH
> system-wide.  In my experience, such a setup is actually easier to
> debug than one where individual applications or libraries each have
> their own idea of where to look for 'modules'.

No, I hadn't any problems with the way Perl handles this (or Python,
which is similar). As an additional bonus you get version separation
for (nearly) free. Of course this should be just one of the `standard
places' the interpreter looks into. I'm completely in agreement with
you that there should be libs that are useful *independently of guile*,
and those should go to the system standard places.

> Instead of LD_LIBRARY_PATH, a better place might be /etc/ld.so.conf or
> equivalent.

As someone else said (Rob?) *Oh, yes, please*, but that seems to be
rather a libtool issue, doesn't it?

> I would agree that traditional Unix is generally bad at keeping each
> package into its own private location. [...]

Yep. But other kids do it ;-)

> This is not the optimal situation, and a more flexible naming scheme
> for libraries is maybe needed, but I don't think we should develop
> such a thing for Guile's private amusement.

No, but following practices from the other Big Ones (the interpreters
with the Big P on them, you know, wink, wink ;-) might be worth
considering (depending, of course, on what the others say here...).

> I'm all for experimenting, and we should take care that people can
> easily experiment on a higher-level using Guile's lower-level support.
> Thus, it should be definitely possible to pass absolute file names to
> dynamic-link and load-extension such that people can implement their
> own searching algorithms, for example.

Maybe having a %ld-library-path% or similar which is taken into account
at lt_dlopen() time (by properly calling lt_dlsetsearchpath() and/or
lt_dladdsearchdir() as appropriate before and resetting the values after
if necessary) could be something we could agree upon? What do others
think?

Thanks
-- tomas


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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:
>[...]
> 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.

Hmm, not really, if we use either only add via 'lt_dladdsearchpath()'
or create our own and incorporate whatever lt_dlgetsearchpath()' returns.

 Ralf


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Paul Jarc]

Rob Browning <rlb@defaultvalue.org> wrote:
> prj@po.cwru.edu (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.

I don't think it would.  This modification would be done only when
linking one of Guile's own libraries, so it wouldn't affect searches
for other libraries, and it would be undone after the library was
linked in.

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

Sounds good.  Making libltdl search the compile-time -rpath
directories would be a good general solution.


paul


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Neil Jerram]

>>>>> "Rob" == Rob Browning <rlb@defaultvalue.org> writes:

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

But what `more general solution' do you (or anyone else) envisage?
There aren't that many variables in this problem.

Or, to put it another way, proposing something concrete is more likely
to obtain a clear response from the libltdl people than saying `we
don't know what to do, what do you think?'.

(On versioning, I think that speaking with the libltdl people is
exactly the right thing to do.  But AFAIU versioning is an orthogonal
issue to the library location one, and a more complex one where
libtool people are likely to have thought much more than us already.)

Regards,
        Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Rob Browning]

Neil Jerram <neil@ossau.uklinux.net> writes:

> Or, to put it another way, proposing something concrete is more likely
> to obtain a clear response from the libltdl people than saying `we
> don't know what to do, what do you think?'.

Well I'm presuming they have a lot more experience with the problem,
especially cross-platform, than I do.  Things I'd suggest without
knowing any better:

  - versioned open: lt_dlopen_interface (char *name, int interface_num),
    where number is the libtool interface number that needs to be
    satisfied.

  - this would probably require a versioned .la file or something
    similar, perhaps libfoo.la.A.B.C.  This would have affects on
    compile time, build time, install time, and runtime.

  - see if it's possible to have libltdl use the same algorithm that
    ld.so does on any given platform to compute the library to load.
    Ideally, the search algorithm might be provided on platforms where
    it's feasible by libc or similar low-level library.

I've asked about this on the libtool side before on a couple of
occasions, but have had no response, though perhaps I somehow
approached them poorly.

> (On versioning, I think that speaking with the libltdl people is
> exactly the right thing to do.  But AFAIU versioning is an orthogonal
> issue to the library location one, and a more complex one where
> libtool people are likely to have thought much more than us already.)

They're related in the sense that having versioned .la files means
that you at least don't have to use path or naming tricks for the
common case where you have two binary incompatible versions of libfoo.

Without the versioned dlopen, you have to either use separate
subdirectories, or naming hacks (we chose the latter in guile -- hence
libguilereadline-v-12) to make sure you load the one you meant to.  As
it stands, (dynamic-link "libfoo") might get you *any* libfoo.

If we had versioning, then we could just put both versions of the
library in the same directory (/usr/lib, or whatever), and say

  (dynamic-link "libfoo" 9)
or
  (dynamic-link "libfoo" 12)

and let libltdl figure it out the same way ld.so does for
compile/launch time links.

You're right though, that even with this fix, and with a modified
libltdl that respects the same things that ld.so does, you still have
some of the same "do we use -rpath, require LD_LIBRARY_PATH, or
something else" questions for guile when it's installed outside of
/usr or /usr/local.

Requiring LD_LIBRARY_PATH to be set right is the most common approach
I've seen, but that doesn't mean we have to do things that way.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Paul Jarc]

Rob Browning <rlb@defaultvalue.org> wrote:
> You're right though, that even with this fix, and with a modified
> libltdl that respects the same things that ld.so does, you still have
> some of the same "do we use -rpath, require LD_LIBRARY_PATH, or
> something else" questions for guile when it's installed outside of
> /usr or /usr/local.

If libltdl is so modified, then regardless of what Guile does, -rpath
will at least be *available* for those who want tp use it, and
LD_LIBRARY_PATH will (as now) be available for those who don't.  Some
packages provide a ./configure option to specify whether -rpath should
be used automatically.


paul


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Rob Browning]

prj@po.cwru.edu (Paul Jarc) writes:

> If libltdl is so modified, then regardless of what Guile does, -rpath
> will at least be *available* for those who want tp use it, and
> LD_LIBRARY_PATH will (as now) be available for those who don't.  Some
> packages provide a ./configure option to specify whether -rpath should
> be used automatically.

Oh right.  I agree.  I just meant that we'd still have to decide what
to do in guile one way or the other.  Do we use rpath, do we make it
an option, etc...

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Thien-Thi Nguyen]

   From: prj@po.cwru.edu (Paul Jarc)
   Date: Wed, 18 Sep 2002 18:43:59 -0400

   By "temporarily", I meant that the modification should be undone after
   linking the library.  Would this problem still remain then?

best way to find the answer is to try.  e.g., 1.4.1.88 does this, but
using low-level libltdl search-path munging mechanisms instead of env
vars (same idea, though).  you could install 1.4.1.88 in /tmp/a/b/c and
see how it behaves.  i would welcome suggestions on how to improve the
implementation (see end of ice-9/boot-9/module-system.scm).

thi


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Paul Jarc]

Thien-Thi Nguyen <ttn@giblet.glug.org> wrote:
> you could install 1.4.1.88 in /tmp/a/b/c and see how it behaves.

It didn't compile; I don't have "." in my $PATH.

--- guile-1.4.1.88/ice-9/Makefile.in~   2002-09-18 14:39:17.000000000 -0400
+++ guile-1.4.1.88/ice-9/Makefile.in    2002-09-19 11:59:58.000000000 -0400
@@ -490,7 +490,7 @@
        sed -f $(srcdir)/../scripts/config-status-vars.sed \
            -f $(srcdir)/make-gbi.sed \
            ../config.status > GBIFRAG
-       prefix=$(prefix); exec_prefix=$(exec_prefix); . GBIFRAG > TMP
+       prefix=$(prefix); exec_prefix=$(exec_prefix); . ./GBIFRAG > TMP
        $(SHELL) $(srcdir)/generate-boot-9.sh $(srcdir) $< \
          | sed -e '/%guile-build-info scan data/r TMP' \
                -e '/%guile-build-info scan data/d' \

--- guile-1.4.1.88/check-guile.in~      2002-09-07 21:30:39.000000000 -0400
+++ guile-1.4.1.88/check-guile.in       2002-09-19 12:00:16.000000000 -0400
@@ -24,7 +24,7 @@
 
 set -ex
 
-exec pre-inst-guile-tools run-all-tests \
+exec ./pre-inst-guile-tools run-all-tests \
      --tests-dir ${srcdir}/test-suite/tests \
      --preload ${srcdir}/test-suite/prologue.scm \
      --log check-guile.log \

With those changes, it compiles, installs, and passes "make check".
When I run it, I can do this:
guile> (use-modules (ice-9 readline))
guile> (activate-readline)
#t
guile> (readline-options 'full
But when I type the closing paren, I get:
./j/guile-1.4.1.88/bin/guile: relocation error: /home/prj/src/sptools/j/guile-1.4.1.88/lib/guile/1.4.1.88/modules/libguilereadline.so.0: undefined symbol: scm_internal_select


paul


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Thien-Thi Nguyen]

   From: prj@po.cwru.edu (Paul Jarc)
   Date: Thu, 19 Sep 2002 12:17:36 -0400

   -       prefix=$(prefix); exec_prefix=$(exec_prefix); . GBIFRAG > TMP
   +       prefix=$(prefix); exec_prefix=$(exec_prefix); . ./GBIFRAG > TMP

cool, thanks for the fix.  installed in cvs.

   [...] relocation error: [...] undefined symbol: scm_internal_select

does the appended patch fix this problem?

thi

____________________________
Index: readline.c
===================================================================
RCS file: /home/ttn/cvs/guile-core/guile-readline/readline.c,v
retrieving revision 1.3
diff -w -c -b -c -r1.3 readline.c
*** readline.c	29 Aug 2002 06:14:40 -0000	1.3
--- readline.c	19 Sep 2002 18:48:51 -0000
***************
*** 489,494 ****
--- 489,501 ----
    return -1;
  }
  
+ /* todo: move to libguile.h */
+ #ifdef GUILE_ISELECT
+ # define SCM_SELECT scm_internal_select
+ #else
+ # define SCM_SELECT select
+ #endif
+ 
  static int
  match_paren (int x, int k)
  {
***************
*** 519,525 ****
        if (rl_point > -1)
  	{
  	  rl_redisplay ();
! 	  scm_internal_select (fno + 1, &readset, NULL, NULL, &timeout);
  	}
        rl_point = tmp;
      }
--- 526,532 ----
        if (rl_point > -1)
  	{
  	  rl_redisplay ();
! 	  SCM_SELECT (fno + 1, &readset, NULL, NULL, &timeout);
  	}
        rl_point = tmp;
      }


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Paul Jarc]

Thien-Thi Nguyen <ttn@giblet.glug.org> wrote:
>    From: prj@po.cwru.edu (Paul Jarc)
>    Date: Thu, 19 Sep 2002 12:17:36 -0400
>
>    -       prefix=$(prefix); exec_prefix=$(exec_prefix); . GBIFRAG > TMP
>    +       prefix=$(prefix); exec_prefix=$(exec_prefix); . ./GBIFRAG > TMP
>
> cool, thanks for the fix.  installed in cvs.

Did you also see the one for check-guile.in?

>    [...] relocation error: [...] undefined symbol: scm_internal_select
>
> does the appended patch fix this problem?

Guile no longer crashes.  Now I get:
guile> (use-modules (ice-9 readline))
guile> (activate-readline)
#t
guile> (readline-options 'full)
ERROR: Unbound variable: readline-options-interface
ABORT: (unbound-variable)


paul


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Thien-Thi Nguyen]

   From: prj@po.cwru.edu (Paul Jarc)
   Date: Thu, 19 Sep 2002 15:33:49 -0400

   Did you also see the one for check-guile.in?

now i see it.  fix installed.  thanks.

   ERROR: Unbound variable: readline-options-interface
   ABORT: (unbound-variable)

currently investigating, will get back later w/ report.

thi


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Thien-Thi Nguyen]

   From: Thien-Thi Nguyen <ttn@giblet.glug.org>
   Date: Thu, 19 Sep 2002 12:58:22 -0700

   currently investigating, will get back later w/ report.

ok, check out the patch below.  it extracts option interface init to new
proc `%define-option-interface' and adds a call to that to the readline
init flow.

note that you should apply it from the top of the build tree and then do
"make" to recompose ice-9/boot-9.scm before "make install".

these readline bugs touch upon a hole in our testing; we have mechanism
to do "expect"-like tests but do not make use of it.  i guess this means
someone needs to do that... (grumble grumble :-).

thi

_________________________________________
cd ~/build/GNU/guile/hack/core-1-4/
cvs diff -rdynamic-readline-broken ice-9/boot-9/runtime-options.scm guile-readline/readline.scm
Index: ice-9/boot-9/runtime-options.scm
===================================================================
RCS file: /home/ttn/cvs/guile-core/ice-9/boot-9/runtime-options.scm,v
retrieving revision 1.2
retrieving revision 1.3
diff -c -r1.2 -r1.3
*** ice-9/boot-9/runtime-options.scm	29 Aug 2002 06:28:26 -0000	1.2
--- ice-9/boot-9/runtime-options.scm	19 Sep 2002 21:57:42 -0000	1.3
***************
*** 43,138 ****
  
  ;;; {Run-time options}
  
! ((let* ((names '((eval-options-interface
! 		  (eval-options eval-enable eval-disable)
! 		  (eval-set!))
! 
! 		 (debug-options-interface
! 		  (debug-options debug-enable debug-disable)
! 		  (debug-set!))
! 
! 		 (evaluator-traps-interface
! 		  (traps trap-enable trap-disable)
! 		  (trap-set!))
! 
! 		 (read-options-interface
! 		  (read-options read-enable read-disable)
! 		  (read-set!))
! 
! 		 (print-options-interface
! 		  (print-options print-enable print-disable)
! 		  (print-set!))
! 
! 		 (readline-options-interface
! 		  (readline-options readline-enable readline-disable)
! 		  (readline-set!))
! 		 ))
! 	(option-name car)
! 	(option-value cadr)
! 	(option-documentation caddr)
! 
! 	(print-option (lambda (option)
! 			(display (option-name option))
! 			(if (< (string-length
! 				(symbol->string (option-name option)))
! 			       8)
! 			    (display #\tab))
! 			(display #\tab)
! 			(display (option-value option))
! 			(display #\tab)
! 			(display (option-documentation option))
! 			(newline)))
! 
! 	;; Below follows the macros defining the run-time option interfaces.
! 
! 	(make-options (lambda (interface)
! 			`(lambda args
! 			   (cond ((null? args) (,interface))
! 				 ((list? (car args))
! 				  (,interface (car args)) (,interface))
! 				 (else (for-each ,print-option
! 						 (,interface #t)))))))
! 
! 	(make-enable (lambda (interface)
! 		       `(lambda flags
! 			  (,interface (append flags (,interface)))
! 			  (,interface))))
  
! 	(make-disable (lambda (interface)
  			`(lambda flags
! 			   (let ((options (,interface)))
! 			     (for-each (lambda (flag)
! 					 (set! options (delq! flag options)))
! 				       flags)
! 			     (,interface options)
! 			     (,interface)))))
! 
! 	(make-set! (lambda (interface)
! 		     `((name exp)
! 		       (,'quasiquote
! 			(begin (,interface (append (,interface)
! 						   (list '(,'unquote name)
! 							 (,'unquote exp))))
! 			       (,interface))))))
! 	)
!    (procedure->macro
       (lambda (exp env)
         (cons 'begin
! 	     (apply append
! 		    (map (lambda (group)
! 			   (let ((interface (car group)))
! 			     (append (map (lambda (name constructor)
! 					    `(define ,name
! 					       ,(constructor interface)))
! 					  (cadr group)
! 					  (list make-options
! 						make-enable
! 						make-disable))
! 				     (map (lambda (name constructor)
! 					    `(defmacro ,name
! 					       ,@(constructor interface)))
! 					  (caddr group)
! 					  (list make-set!)))))
! 			 names)))))))
  
  ;;; runtime-options.scm ends here
--- 43,137 ----
  
  ;;; {Run-time options}
  
! (define %define-option-interface
!   (let* ((option-name car)
! 	 (option-value cadr)
! 	 (option-documentation caddr)
! 
! 	 (print-option (lambda (option)
! 			 (display (option-name option))
! 			 (if (< (string-length
! 				 (symbol->string (option-name option)))
! 				8)
! 			     (display #\tab))
! 			 (display #\tab)
! 			 (display (option-value option))
! 			 (display #\tab)
! 			 (display (option-documentation option))
! 			 (newline)))
! 
! 	 ;; Below follow the macros defining the run-time option interfaces.
! 
! 	 (make-options (lambda (interface)
! 			 `(lambda args
! 			    (cond ((null? args) (,interface))
! 				  ((list? (car args))
! 				   (,interface (car args)) (,interface))
! 				  (else (for-each ,print-option
! 						  (,interface #t)))))))
  
! 	 (make-enable (lambda (interface)
  			`(lambda flags
! 			   (,interface (append flags (,interface)))
! 			   (,interface))))
! 
! 	 (make-disable (lambda (interface)
! 			 `(lambda flags
! 			    (let ((options (,interface)))
! 			      (for-each (lambda (flag)
! 					  (set! options (delq! flag options)))
! 					flags)
! 			      (,interface options)
! 			      (,interface)))))
! 
! 	 (make-set! (lambda (interface)
! 		      `((name exp)
! 			(,'quasiquote
! 			 (begin (,interface (append (,interface)
! 						    (list '(,'unquote name)
! 							  (,'unquote exp))))
! 				(,interface)))))))
!     (procedure->memoizing-macro
       (lambda (exp env)
         (cons 'begin
! 	     (let* ((option-group (cadr exp))
! 		    (interface (car option-group)))
! 	       (append (map (lambda (name constructor)
! 			      `(define ,name
! 				 ,(constructor interface)))
! 			    (cadr option-group)
! 			    (list make-options
! 				  make-enable
! 				  make-disable))
! 		       (map (lambda (name constructor)
! 			      `(defmacro ,name
! 				 ,@(constructor interface)))
! 			    (caddr option-group)
! 			    (list make-set!)))))))))
! 
! (%define-option-interface
!  (eval-options-interface
!   (eval-options eval-enable eval-disable)
!   (eval-set!)))
! 
! (%define-option-interface
!  (debug-options-interface
!   (debug-options debug-enable debug-disable)
!   (debug-set!)))
! 
! (%define-option-interface
!  (evaluator-traps-interface
!   (traps trap-enable trap-disable)
!   (trap-set!)))
! 
! (%define-option-interface
!  (read-options-interface
!   (read-options read-enable read-disable)
!   (read-set!)))
! 
! (%define-option-interface
!  (print-options-interface
!   (print-options print-enable print-disable)
!   (print-set!)))
  
  ;;; runtime-options.scm ends here
Index: guile-readline/readline.scm
===================================================================
RCS file: /home/ttn/cvs/guile-core/guile-readline/readline.scm,v
retrieving revision 1.5
retrieving revision 1.6
diff -c -r1.5 -r1.6
*** guile-readline/readline.scm	29 Aug 2002 06:15:22 -0000	1.5
--- guile-readline/readline.scm	19 Sep 2002 22:07:52 -0000	1.6
***************
*** 59,64 ****
--- 59,66 ----
  
  (load-guile-internal-module "guilereadline")
  
+ ;; todo: move this before `define-module' once registration is external.
+ ;;       see (ice-9 threads) for example.
  (or (feature? 'readline)
      (error "readline is not provided in this Guile installation"))
  
***************
*** 208,212 ****
--- 210,227 ----
  		      (set-readline-prompt! "" "")
  		      (set-readline-read-hook! #f)))))
  	(set! (using-readline?) #t))))
+ 
+ ;; Define the options.
+ 
+ (%define-option-interface
+   (readline-options-interface
+    (readline-options readline-enable readline-disable)
+    (readline-set!)))
+ 
+ (export readline-options-interface
+         readline-options
+         readline-enable
+         readline-disable
+         readline-set!)
  
  ;;; readline.scm ends here

Compilation exited abnormally with code 1 at Thu Sep 19 15:08:47


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Thien-Thi Nguyen]

   From: Thien-Thi Nguyen <ttn@giblet.glug.org>
   Date: Thu, 19 Sep 2002 15:17:15 -0700

   ok, check out the patch below.

alternatively, 1.4.1.89 includes those changes:

  http://www.glug.org/tmp/2002-09/

thi


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Paul Jarc]

Thien-Thi Nguyen <ttn@giblet.glug.org> wrote:
> alternatively, 1.4.1.89 includes those changes:
>
>   http://www.glug.org/tmp/2002-09/

That version works for me.
$ ./j/guile-1.4.1.89/bin/guile
guile> (use-modules (ice-9 readline))
guile> (activate-readline)
#t
guile> (readline-options 'full)
bounce-parens   500     Time (ms) to show matching opening parenthesis (0 = off).
history-length  200     History length.
history-file    yes     Use history file.
guile> (readline-disable 'history-file)
(bounce-parens 500 history-length 200)
guile> (readline-options 'full)
bounce-parens   500     Time (ms) to show matching opening parenthesis (0 = off).
history-length  200     History length.
history-file    no      Use history file.


paul


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Marius Vollmer]

prj@po.cwru.edu (Paul Jarc) writes:

> > Your suggestions work against the usual means of managing shared
> > libraries, not with them.  I think we should work with them, even if
> > they are slightly broken.
> 
> I think we should fix them.

I wont stop you. ;-)

> But how about this: when linking one of Guile's own libraries,
> temoporarily prepend (assq-ref %guile-build-info 'libdir) to
> LD_LIBRARY_PATH or LTDL_LIBRARY_PATH, whichever is searched first.
> Would that satisfy everyone?

Why is that better than always and system-wide prepending $(libdir) to
LD_LIBRARY_PATH?

> > Instead, you should configure the whole system to look into the right
> > places.
> 
> On my system, each installation of each version of each package gets
> its own unique installation prefix.  I configure each package to find
> the libraries it needs at compile time; LD_LIBRARY_PATH would be
> awfully big if I didn't.

Why is it a problem to have a long LD_LIBRARY_PATH?  You do need a
long PATH already, no?

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Paul Jarc]

Marius Vollmer <mvo@zagadka.ping.de> wrote:
> prj@po.cwru.edu (Paul Jarc) writes:
>> But how about this: when linking one of Guile's own libraries,
>> temoporarily prepend (assq-ref %guile-build-info 'libdir) to
>> LD_LIBRARY_PATH or LTDL_LIBRARY_PATH, whichever is searched first.
>> Would that satisfy everyone?
>
> Why is that better than always and system-wide prepending $(libdir) to
> LD_LIBRARY_PATH?

It's less error-prone.  LD_LIBRARY_PATH can be gotten wrong after
installation - by users.  Whereas if Guile looks in libdir
automatically (as it could with a fixed libltdl), then as long as
installation was done correctly, users can't shoot themselves in the
foot that way.

>> On my system, each installation of each version of each package gets
>> its own unique installation prefix.  I configure each package to find
>> the libraries it needs at compile time; LD_LIBRARY_PATH would be
>> awfully big if I didn't.
>
> Why is it a problem to have a long LD_LIBRARY_PATH?

Environment space is limited, so that scales only so far.  I don't
know what the limit is for rpath, if any, but per-package compile-time
configuration can be limited to include only the libraries that that
package needs, so it doesn't grow as fast anyway.

> You do need a long PATH already, no?

No.  All commands are symlinked in /command, so that's the only
directory in my global PATH.  But that's a wart, it's one more thing
to have to maintain, and I don't want to have to create a similar one
for libraries.


paul


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Marius Vollmer]

prj@po.cwru.edu (Paul Jarc) writes:

> > Why is that better than always and system-wide prepending $(libdir) to
> > LD_LIBRARY_PATH?
> 
> It's less error-prone.  LD_LIBRARY_PATH can be gotten wrong after
> installation - by users.  Whereas if Guile looks in libdir
> automatically (as it could with a fixed libltdl), then as long as
> installation was done correctly, users can't shoot themselves in the
> foot that way.

But that might come back to hunt them later.  Guile will be able to
magically find libraries that can't otherwise be found.  I really do
strongly believe that when you install software into /usr/local but
the system can't find shared libraries in /usr/local/lib by default,
then the system is not correctly configured, not the package that has
been installed into /usr/local.  Same with any other prefix.

> > You do need a long PATH already, no?
> 
> No.  All commands are symlinked in /command, so that's the only
> directory in my global PATH.  But that's a wart, it's one more thing
> to have to maintain, and I don't want to have to create a similar one
> for libraries.

Everything thing else will be a bigger wart, in my opinion.  You might
not want to deal with it, but Guile is not the place to take care of
it, either.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Paul Jarc]

Marius Vollmer <mvo@zagadka.ping.de> wrote:
> I really do strongly believe that when you install software into
> /usr/local but the system can't find shared libraries in
> /usr/local/lib by default, then the system is not correctly
> configured, not the package that has been installed into /usr/local.
> Same with any other prefix.

Ok, but my way of configuring the system to find those libraries is to
use ld -R.  If libltdl is fixed to look in such directories, then each
admin gets to choose whether to use -R or LD_LIBRARY_PATH on their own
systems, so everybody's happy.  Right?

I'm not asking for Guile to automatically supply -R${libdir}.  I can
add that to LDFLAGS myself, and those who don't like that way of doing
things can leave it out.  But I would like for -R${libdir} to be used
by libltdl, if I supply it.


paul


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Marius Vollmer]

prj@po.cwru.edu (Paul Jarc) writes:

> Marius Vollmer <mvo@zagadka.ping.de> wrote:
> > I really do strongly believe that when you install software into
> > /usr/local but the system can't find shared libraries in
> > /usr/local/lib by default, then the system is not correctly
> > configured, not the package that has been installed into /usr/local.
> > Same with any other prefix.
> 
> Ok, but my way of configuring the system to find those libraries is to
> use ld -R.  If libltdl is fixed to look in such directories, then each
> admin gets to choose whether to use -R or LD_LIBRARY_PATH on their own
> systems, so everybody's happy.  Right?

Yep, definitely.  I just checked, and dlopen on GNU/Linux seems to
respect "-R" and since libltdl falls back on the native dlopen, you
should be fine.  I think that bugs in libltdl have prevented it from
falling back gracefully, but you should have a fixed libltdl soon.

With the fixed libltdl, my Guile 1.6.0 installation in /usr/local/ can
find libguilereadline-v-12.so in /usr/local/lib even when
/usr/local/lib is neither in /etc/ld.so.conf nor in LD_LIBRARY_PATH
(or any other env var).

(We still ahve the problem that we can't currently specify a interface
number of major version to load-extension, but you hack around tis for
the time being by including the major version in the library name
itself.)

> I'm not asking for Guile to automatically supply -R${libdir}.  I can
> add that to LDFLAGS myself, and those who don't like that way of
> doing things can leave it out.  But I would like for -R${libdir} to
> be used by libltdl, if I supply it.

This will be the case in 1.6.1, at least with the GNU libc.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Paul Jarc]

Marius Vollmer <mvo@zagadka.ping.de> wrote:
> prj@po.cwru.edu (Paul Jarc) writes:
>> But I would like for -R${libdir} to be used by libltdl, if I supply
>> it.
>
> This will be the case in 1.6.1, at least with the GNU libc.

Great, thanks.


paul


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[tomas]

On Wed, Oct 09, 2002 at 12:47:09AM +0200, Marius Vollmer wrote:
> prj@po.cwru.edu (Paul Jarc) writes:
> 
> > Marius Vollmer <mvo@zagadka.ping.de> wrote:

[...]

> Yep, definitely.  I just checked, and dlopen on GNU/Linux seems to
> respect "-R" and since libltdl falls back on the native dlopen, you
> should be fine.  I think that bugs in libltdl have prevented it from
> falling back gracefully, but you should have a fixed libltdl soon.

(see posting on other thread)

So that means that one of the problems is solved. Horay!

thanks
-- tomas


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Arno Peters]

On Wed, Sep 18, 2002 at 11:14:14PM +0200, Marius Vollmer wrote:
> 
> So, in my view, the right fix is to set LD_LIBRARY_PATH or
> LTDL_LIBRARY_PATH.

I have two versions of Guile installed: 1.4 in /usr and 1.7 in
/usr/local.  If I leave LTDL_LIBRARY_PATH undefined, version 1.4 works
flawlessly with libreadline but version 1.7 crashes hard.  If I define
LTDL_LIBRARY_PATH=/usr/local/lib version 1.7 works flawlessly with
libreadline but version 1.4 crashes hard.

In either case, one guile does not work.  This is unacceptable for me.

> It would also be acceptable to change Guile to also look into the
> directories from /etc/ld.so.conf on GNU/Linux, and generally to follow
> the behavior of dlopen as closely as possible.  (One should also fix
> ld to be consistent with ld.so.)

This would indeed do the trick.

Greetings,
-- 
Arno



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Rob Browning]

Arno Peters <a.w.peters@ieee.org> writes:

> I have two versions of Guile installed: 1.4 in /usr and 1.7 in
> /usr/local.  If I leave LTDL_LIBRARY_PATH undefined, version 1.4 works
> flawlessly with libreadline but version 1.7 crashes hard.  If I define
> LTDL_LIBRARY_PATH=/usr/local/lib version 1.7 works flawlessly with
> libreadline but version 1.4 crashes hard.
>
> In either case, one guile does not work.  This is unacceptable for me.

Do we know why it crashes?  I don't have a 1.7 install available right
this minute, but I'm guessing it's a bug.  Does it happen with 1.6.0?

There are still some build/versioning changes I need to migrate to 1.7
from the 1.6 tree, and that might be the problem.  In theory, 1.6 and
1.7 should be putting the major version number in the lib names and so
shouldn't have any conflicts with each other or older guile versions.
Of course from now on, we should only be changing the major numbers
when appropriate or we lose the ability to install a bugfixed library
without having to recompile all the apps that depend on it.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Marius Vollmer]

Arno Peters <a.w.peters@ieee.org> writes:

> On Wed, Sep 18, 2002 at 11:14:14PM +0200, Marius Vollmer wrote:
> > 
> > So, in my view, the right fix is to set LD_LIBRARY_PATH or
> > LTDL_LIBRARY_PATH.
> 
> I have two versions of Guile installed: 1.4 in /usr and 1.7 in
> /usr/local.  If I leave LTDL_LIBRARY_PATH undefined, version 1.4 works
> flawlessly with libreadline but version 1.7 crashes hard.  If I define
> LTDL_LIBRARY_PATH=/usr/local/lib version 1.7 works flawlessly with
> libreadline but version 1.4 crashes hard.
> 
> In either case, one guile does not work.  This is unacceptable for me.

Yes, this is a bug in 1.7.  Guile 1.6.0 does not have this bug and
should work fine in this setup. (Does it?)

The problem is that we currently can't specify a particular version
when calling 'dynamic-link' or 'load-extension'.  Once we can, this
problem should go away.

> > It would also be acceptable to change Guile to also look into the
> > directories from /etc/ld.so.conf on GNU/Linux, and generally to follow
> > the behavior of dlopen as closely as possible.  (One should also fix
> > ld to be consistent with ld.so.)
> 
> This would indeed do the trick.

We hope to implement this soon, by using our own variant of libltdl.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Rob Browning]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> Yes, this is a bug in 1.7.  Guile 1.6.0 does not have this bug and
> should work fine in this setup. (Does it?)

There's currently some funny-business in HEAD -- I have some library
work I did in 1.6 that I haven't ported forward to HEAD.  I'll be
doing that soon.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Greg Troxel]

I'll try to step back and take a broader look - there are multiple
issues here.

1) 'Shared libraries' and guile's dlopening of libguilereadline-v-12
   are not the same thing.  A normal usage of a shared library
   involves link-time binding of the library to the binary.
   For example, the guile binary refers to libguile.so.15 and
   libltdl.so.4.
   The search paths for resolving these libraries at run-time is given
   by '-R' linker options, at least on BSD.  Thus, these libraries can
   be found in the appropriate place at runtime without  having to set
   environment variables.
   Further, I believe that programs linked against different versions
   of libguile.so.15 will each find the right one, due to the
   differing -R options at link time.

   dlopening does not use this link-time binding.  (perhaps on NetBSD
   the -R values are being used by dlopen

2) On BSD ELF systems, it is my opinion that having to have set
   LD_LIBRARY_PATH is a sign of underlying brokenness.  I have not had
   to do this other than guile.  So it's a warning sign that guile
   seems to require setting this variable.

3) Stepping back from shared library issues and assuming we have
   infinitely wonderful support, consider the correct behavior.  Guile
   installs a bunch of .scm files and a bunch of .so files that
   libguile uses for various purposes.  The guile installation is a
   complete set, and it doesn't make much sense to mix and match files
   between installations.  If one has multiple copies of 1.6 (perhaps
   some hacked up in various ways) installed, each guile binary in
   /usr/guile16-foo/bin should get the corresponding
   /usr/guile16-foo/share/guile/1.6.0/ice-9/*.scm and
   /usr/guile16-foo/lib/libguilereadline-v-12 dynamic object
   (similarly for /usr/guile16-bar).  Looking anyplace else for this
   shared object, like /usr/bin, or /usr/local/bin, is simply the
   wrong thing to do - the build did not put it there and any such
   files are either cruft or part of a different build of guile.  It
   would be equally broken to link in
   /usr/lib/libguilereadline-v-12.so as it would be for
   /usr/guile16-foo/bin/guile to read ice-9 stuff from
   /usr/share/guile/1.6.0/ice-9.
   (One can argue for looking for modules in other places, but that's
   a different story from things that are "part of guile").

   I don't understand the notion of prepending $(libdir) to the search
   path as the right answer; this will still look in other places, and
   I think it is incorrect to even try those other places for files
   that are part of guile.

4) Setting LD_LIBRARY_PATH can't work in general.   If one had two
   guile installations in /usr/guile16-{foo,bar}, one of the lib dirs
   has to come first.  The other installation will dlopen the wrong .so
   files.

5) LD_LIBRARY_PATH doesn't work in setuid/setgid situations.  Guile
   should not foreclose this option.

In general, I think the -R concept for shared libraries has been a big
win - library locations get bound into the dynamic executable, rather
than having system changes over time cause libraries in different
directories to get loaded.  So I freely admit that this biases my opinions.

If one accepts my point 3, then it follows that guile should try to
dlopen libguilereadline-v-12.so from _exactly one place_, the place
where the guile build put it.  So I argue that using any sort of
search path is incorrect for these objects.

Thus, I think we need a new procedure that takes an absolute pathname
of a .so and dlopens it without doing any search operations, and
should call that with the libdir value from the build-time
configuration.  Passing the absolute path to the current procedure
appears to more-or-less do this, although it might search for
/usr/lib/usr/foo/lib/libguilereadline-v-12.  With this absolute-path
scheme, guile and guile-using-applications will work correctly without
needing to set any environment variables.

It looks like libltdl:try_dlopen needs only to check if the first
character is / and then not do the searching steps in order to fully
implement the above scheme.

I don't think there are any downsides to the try-exactly-one-place
approach, other than perhaps having to modify libltdl to really
implement it.  AFAIK, guile already does not support the notion of
putting the bits in other than the prefix they were built for.

        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Rob Browning]

Greg Troxel <gdt@ir.bbn.com> writes:

>    dlopening does not use this link-time binding.  (perhaps on NetBSD
>    the -R values are being used by dlopen

Likely for loading inter-linked libraries, but I'd guess not for the
initial top-level dlopen.

> 2) On BSD ELF systems, it is my opinion that having to have set
>    LD_LIBRARY_PATH is a sign of underlying brokenness.  I have not had
>    to do this other than guile.  So it's a warning sign that guile
>    seems to require setting this variable.

You don't have to do that if you install an app to /opt/foo?  I think
part of the problem here is that libltdl's failure to match ld.so's
behavior is exposing the "special nature" on most systems of
/usr/local.

> 4) Setting LD_LIBRARY_PATH can't work in general.   If one had two
>    guile installations in /usr/guile16-{foo,bar}, one of the lib dirs
>    has to come first.  The other installation will dlopen the wrong .so
>    files.

Yes, though that's what you'd expect under the traditional unix model.
You can't have two versions of the same app installed in different
locations and expect to select which one you want to run without
changing any of your environment variables (or other configuration
bits).  I tend to doubt most people are going to need to have (and
switch between) multiple copies of the same version of guile, and
those that do, are probably developers and can write up a little
"guile-env" script that lets you run whichever you want "guile-env
1.5.7 guile --version", etc.

This "multiple copies problem" exists with *any* app that includes its
own shared libraries.  Granted the -rpath mechanism does fix it in
some sense, but if we don't respect the standard
LD_LIBRARY_PATH/ld.so.conf mechanism, are we sure we don't end up
(even if only on some platforms) with strange multiple-version linking
problems for apps that link to a set of libs that have their own
interdependencies?  Put another way, how do we make sure that apps
built at different points in time against libs with their own
interdependencies don't end up runtime linked against multiple
versions of libguile, or libguile-srfi-*?  With the
LD_LIBRARY_PATH/ld.so.conf setup, it's clear.  There's only one
possible choice at runtime.  It's it also clear if everything uses
-rpath?  Can two different libraries have -rpaths pointing to two
different copies of the same sub-library?

I'm not sure this is a serious problem, and perhaps just mandating the
use of guile-config fixes it, but it's something I think we should
consider.

> 5) LD_LIBRARY_PATH doesn't work in setuid/setgid situations.  Guile
>    should not foreclose this option.

Interesting point I hadn't thought about.

> In general, I think the -R concept for shared libraries has been a
> big win - library locations get bound into the dynamic executable,
> rather than having system changes over time cause libraries in
> different directories to get loaded.  So I freely admit that this
> biases my opinions.

Hmm, well at least in the past (and perhaps still), debian policy
forbid --rpath (I presume the same as -R).  As I recall, the reasoning
for this was that from a system integrator's perspective, using an
rpath causes major problems.  Libraries will need to be moved around
from time to time and if you use rpath, you make it impossible to do
this transparently/incrementally.

And for those who haven't considered (or don't remember), it's not
true that guile's libs are only intended for guile's consumption.  It
is a stated design goal that other apps should be allowed/encouraged
to link directly against guile's libraries, that includes libguile,
libguile-srfi-srfi*, etc.  Apps should be able to use
scm_make_u8vector (), and this means that they have to be able to link
against the library.  So we have to consider our decisions in that
context.

(Come to think of it, given the above, there's a big bug in 1.6.0 --
 none of the srfi.h headers are publically installed...)

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Paul Jarc]

Rob Browning <rlb@defaultvalue.org> wrote:
> This "multiple copies problem" exists with *any* app that includes its
> own shared libraries.

Right, but most of those use ld.so, so they can be handled with
-rpath.

> Granted the -rpath mechanism does fix it in some sense, but if we
> don't respect the standard LD_LIBRARY_PATH/ld.so.conf mechanism

I think the right thing is for libltdl to respect *all* of ld.so's
mechanisms, for the sake of simplicity - you won't have to worry about
which one is being used when you want to configure something to find
libraries somewhere.  Any problem that can occur with -rpath can
already occur with ld.so; any solution for ld.so ought to be usable
with (the hypothetical fixed) libltdl as well.

> I'm not sure this is a serious problem, and perhaps just mandating the
> use of guile-config fixes it, but it's something I think we should
> consider.

I really don't like such *-config programs.  If package foo links to
libraries from package bar, I want foo to find bar via a path other
than bar's installation prefix.  I set up a symlink to bar for foo to
use.  Then when I install a new version of bar (with its own unique
installation prefix), I update the symlink (atomically, even) and foo
finds the new version.

> Hmm, well at least in the past (and perhaps still), debian policy
> forbid --rpath (I presume the same as -R).

Yes.  -R is more portable.

> As I recall, the reasoning for this was that from a system
> integrator's perspective, using an rpath causes major problems.
> Libraries will need to be moved around from time to time and if you
> use rpath, you make it impossible to do this
> transparently/incrementally.

I'm a system integrator too, and I use rpath extensively.  I don't
move libraries or anything else around post-installation.


paul


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Rob Browning]

prj@po.cwru.edu (Paul Jarc) writes:

> I think the right thing is for libltdl to respect *all* of ld.so's
> mechanisms, for the sake of simplicity - you won't have to worry about
> which one is being used when you want to configure something to find
> libraries somewhere.  Any problem that can occur with -rpath can
> already occur with ld.so; any solution for ld.so ought to be usable
> with (the hypothetical fixed) libltdl as well.

That would be fine with me -- frankly I tend to think that runtime
library linking and compile-time library linking should be handled by
the *same* set of people/tools, but we're certainly not there yet :<

> I really don't like such *-config programs.  If package foo links to
> libraries from package bar, I want foo to find bar via a path other
> than bar's installation prefix.  I set up a symlink to bar for foo to
> use.  Then when I install a new version of bar (with its own unique
> installation prefix), I update the symlink (atomically, even) and foo
> finds the new version.

I'm not sure I completely follow.

>> As I recall, the reasoning for this was that from a system
>> integrator's perspective, using an rpath causes major problems.
>> Libraries will need to be moved around from time to time and if you
>> use rpath, you make it impossible to do this
>> transparently/incrementally.
>
> I'm a system integrator too, and I use rpath extensively.  I don't
> move libraries or anything else around post-installation.

I don't fully recall the arguments/rationale, though you could check
the debian-policy or debian-devel archives for more details if you
care (I believe most of this debate pre-dates the debian-policy list).
My impression was that there were times when moving libraries (over
the years) was very hard to avoid, and being able to avoid doing it
en-masse, was somehow a fairly large win.  Perhaps there are some
smart ways to avoid the whole issue, but think that we should be
careful about ignoring this without some investigation.  It's been my
experience (over a long period of time) that debian often has very
good reasons for many of its policies.

Also, what I can say for sure is that unless debian dolicy has
changed, relevant bits of anything that's pacakged for debian will
have to be modified to not set -rpath.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Paul Jarc]

Rob Browning <rlb@defaultvalue.org> wrote:
> I'm not sure I completely follow.

I install bar 1.0 with --prefix=/blah/bar-1.0.  Then:
ln -s bar-1.0 /blah/bar
So the currently installed version of bar is available via
/blah/bar/.  Then I install foo 1.0, which depends on bar:
CPPFLAGS=-I/blah/bar/include LDFLAGS='-L/blah/bar/lib -Wl,-R,/blah/bar/lib' \
./configure --prefix=/blah/foo-1.0
Later, I can install bar 1.1 with --prefix=/blah/bar-1.1, and I can
update the /blah/bar symlink, and foo will now link to the new
libraries.  (If something breaks, I can just switch the symlink back.
Huzzah for reliable upgrades.  If nothing breaks, I can do
"rm -r /blah/bar-1.0".  Huzzah for easy uninstallation.)

But if bar provides a bar-config command, and if foo uses it, then foo
will use /blah/bar-1.0/lib instead of /blah/bar/lib, so it won't pick
up the new version.  Worse, if I don't notice that foo uses
bar-config, then I'll update the symlink, see that foo still works,
and then remove /blah/bar-1.0, breaking foo.

I know that this is a very unusual way of doing things, but it works
very well most of the time.  I get the benefits of package management
along with the benefits of building from source.

> Also, what I can say for sure is that unless debian dolicy has
> changed, relevant bits of anything that's pacakged for debian will
> have to be modified to not set -rpath.

Well, Debian's installation of Guile will be in /usr, won't it?  So it
won't need rpath anyway.  I'm not saying that Guile should be unable
to find its libraries without rpath, but if rpath is set, libltdl (and
thus Guile) should use it the same way ld.so would, in the same order,
etc.  As long as it's possible for me to set rpath for myself, and for
Guile to use that to find its libraries, I'll be happy.


paul


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Rob Browning]

prj@po.cwru.edu (Paul Jarc) writes:

> I know that this is a very unusual way of doing things, but it works
> very well most of the time.  I get the benefits of package management
> along with the benefits of building from source.

OK, now I follow.  Unusual yes, but I can see why it might work well
for you.

> Well, Debian's installation of Guile will be in /usr, won't it?  So
> it won't need rpath anyway.  I'm not saying that Guile should be
> unable to find its libraries without rpath, but if rpath is set,
> libltdl (and thus Guile) should use it the same way ld.so would, in
> the same order, etc.

I think that's something we can all agree on -- consistent behavior
between ld.so and libltdl could only help :>

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Greg Troxel]

I'm afraid I ranted too long and obscured my main point:

For an internal guile extension that gets dlopened, like
guilereadline, there is only one correct place to look, the exact
pathname where the install put it.  Looking anyplace else is broken,
even if it works in most circumstances.

        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Greg Troxel]

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 <gdt@ir.bbn.com>


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Rob Browning]

Greg Troxel <gdt@ir.bbn.com> writes:

> But guile won't work that way, since it needs to find ice-9/foo.scm.

It will if you set GUILE_LOAD_PATH, which is how we traditionally run
guile from a non-install location (which *is* sometimes important --
see below).

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

Since libguilereadline isn't intended to be a public library (unlike
all the others), you're right, it's a more likely candidate for
loading via an absolute path (the install path), but if you do that
you're still going to have the same load failures with
libguile-srfi-srfi-4, etc. -- (use-modules (srfi srfi-4)) will fail
just as readline did.  That's why I've been talking about the libs
other than readline.  We might as well have a solution that works for
all the dlopened libs.

However, without some additional special casing, just putting the
absolute install path into readline.scm will mean that you can't run
guile from the build tree (and still use readline), something that
people can do now (using pre-inst-guile, or suitable envt var
settings), and something we need to do if we want "make check" to be
able to test readline before install.

Now one might argue that "make check" is not critical for readline
(though I'd disagree), but I doubt anyone would argue that it's not
critical for the other libraries, and so we have to be able to run
from a non-install directory.  Of course there are other ways we could
accomodate this need, and perhaps we should investigate those, but at
the moment we ended up with envt vars because that's one of the
traditional unix approaches to this sort of thing (we have
GUILE_LOAD_PATH for the same reason).

I'm definitely not opposed to other solutions, and I can think of a
few myself, but if we change things, I want to try to make sure that
we pick a solution that's definitely an improvement and doesn't make
guile's build/install behaviors too much more complex.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Paul Jarc]

Rob Browning <rlb@defaultvalue.org> wrote:
> Now one might argue that "make check" is not critical for readline
> (though I'd disagree), but I doubt anyone would argue that it's not
> critical for the other libraries, and so we have to be able to run
> from a non-install directory.  Of course there are other ways we could
> accomodate this need, and perhaps we should investigate those,

Here's one I like: <URL:http://cr.yp.to/slashpackage.html>.  This
system puts each installation of each package in its own directory, so
it's safe to install before testing.

I've been meaning to start promoting this to various GNU projects, but
I was going to wait until I got my build system (think autoconf) in
better shape so it would be less work for anyone who wants to convert.
(It also wouldn't hurt to get autoconf/automake on board before going
after anyone else.)  Adopting slashpackage means abandoning the FHS,
but if Guile wants to convert in spite of that, I'd be thrilled.
(Actually, you could maintain both traditional and slashpackage
versions, though I don't know how much extra work that would be.)

OT: naturally, I got impatient, and on my systems, every package is
already installed in its own directory, even the ones that aren't
designed for slashpackage.  I've started to make this into a
distribution: <URL:http://multivac.cwru.edu/sptools/>.  It still needs
lots of polish, and some critical pieces aren't publicly available
yet, but I think it's enough to show that a complete system can in
fact be built this way.


paul


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Rob Browning]

prj@po.cwru.edu (Paul Jarc) writes:

> Adopting slashpackage means abandoning the FHS, but if Guile wants
> to convert in spite of that, I'd be thrilled.  (Actually, you could
> maintain both traditional and slashpackage versions, though I don't
> know how much extra work that would be.)

Hmm.  Way back I used to find that approach appealing, but that was
before I got comfortable with unix.  For my system at least, now that
I use Debian (and it's *good* packaging system) I prefer having all
the conffiles in one subtree, all the executables in another, all the
variable data, etc., but I suspect this is probably a discussion for
some other list...

Last I heard the FSF, at least, was headed further in the direction of
per-type dirs, rather than away from it.  If I understood correctly in
the HURD they have just /bin /lib /var, etc.  However I suppose with
their union fs (where you can merge directories from different
locations onto one mount point), the distinction is a little hazy.
You could still use your approach and just mount /opt/*/bin on /bin,
etc.  Though I wonder how well that would scale for the 1400+ packages
I have installed here :> Suppose it might be fine.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Robert Uhl <ruhl@4dv.net>]

prj@po.cwru.edu (Paul Jarc) writes:
> 
> Here's one I like: <URL:http://cr.yp.to/slashpackage.html>.  This
> system puts each installation of each package in its own directory,
> so it's safe to install before testing.

The problem with that is it makes utter hell out of one's PATH--and
users don't get all apps by default.  Plus you get problems with tools
such as info and man expecting files in certain locations, so you get
to play with MANPATH (and INFOPATH, if there is such a thing).

I like how stow does it: everything goes in its own folder in
/usr/local/stow, and the stow command creates links from
/usr/local/bin, /usr/local/etc &c. to there.  It has some problems
with things like info's dir file--which is an index of all info
files--but a quick hack can fix that.  When you uninstall, you just
run stow -D, which deletes the links.  Then you may remove the
package's directory.

You can also use /usr/stow and get links in /usr/bin, /usr/etc,
/usr/share &c., or ~/stow or what-have-you.  It's a very flexible
tool.

Plus, it's generally as simple as:

    ./configure
    make
    sudo make install prefix=/usr/local/stow/PACKAGE_NAME

which is awfully nice.

> Adopting slashpackage means abandoning the FHS, but if Guile wants
> to convert in spite of that, I'd be thrilled.

I don't think that's a very good idea--the FHS is a nice thing, and
exists for a reason.

-- 
Robert Uhl <ruhl@4dv.net>
Some people are born blind, others are born crippled, and some are born
Americans.  One should not be held responsible for what is essentially an
accident of birth.                                        --Harald Horgen


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Paul Jarc]

ruhl@4dv.net (Robert Uhl <ruhl@4dv.net>) wrote:
> prj@po.cwru.edu (Paul Jarc) writes:
>> <URL:http://cr.yp.to/slashpackage.html>
>
> The problem with that is it makes utter hell out of one's PATH

Nope.  <URL:http://cr.yp.to/slashpackage/management.html>:
       Adding programs to the commands-available-to-users list means
       creating symbolic links in a central directory, /command, as
       well as in /usr/local/bin for compatibility.

> Plus you get problems with tools such as info and man expecting
> files in certain locations, so you get to play with MANPATH (and
> INFOPATH, if there is such a thing).

It does take a bit of extra work to make those things work, but I
think it's worth it.

> I like how stow does it

Stow doesn't have a global registry, so it doesn't solve the problem
of accidental name collisions.  And since all files of the same type
still get squeezed into a flat namespace (.../bin, .../lib, etc.),
collisions are more likely.  With slashpackage, package and command
names are registered so there are no collisions, and other types of
files automatically don't collide because they're in separate
namespaces (i.e., separate directories).

> Plus, it's generally as simple as:
>
>     ./configure
>     make
>     sudo make install prefix=/usr/local/stow/PACKAGE_NAME
>
> which is awfully nice.

With slashpackage, it's as simple as "package/install".

> the FHS is a nice thing, and exists for a reason.

It's well-intentioned, but it doesn't work.  Did you read
<URL:http://cr.yp.to/slashpackage/studies.html>?
The FHS says:
       1.1  Purpose

       This standard enables

          o Software to predict the location of installed files and
            directories, and

          o Users to predict the location of installed files and directories.
But this simply isn't true, as the case studies show.


paul


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Robert Uhl <ruhl@4dv.net>]

prj@po.cwru.edu (Paul Jarc) writes:
>
> > The problem with that is it makes utter hell out of one's PATH
> 
> Nope.  <URL:http://cr.yp.to/slashpackage/management.html>:
>
>    Adding programs to the commands-available-to-users list means
>    creating symbolic links in a central directory, /command, as well
>    as in /usr/local/bin for compatibility.
> 
> > I like how stow does it
> 
> Stow doesn't have a global registry, so it doesn't solve the problem
> of accidental name collisions.  And since all files of the same type
> still get squeezed into a flat namespace (.../bin, .../lib, etc.),
> collisions are more likely.  With slashpackage, package and command
> names are registered so there are no collisions, and other types of
> files automatically don't collide because they're in separate
> namespaces (i.e., separate directories).

I don't see how both of the above can be true.  If two seperate
packages use the same name for a command, then both cannot make that
command available to the user _and_ use the standard name _and_ not
collide.

> > Plus, it's generally as simple as:
> >
> >     ./configure
> >     make
> >     sudo make install prefix=/usr/local/stow/PACKAGE_NAME
> >
> > which is awfully nice.
> 
> With slashpackage, it's as simple as "package/install".

That means a custom install script must be used--with stow, one uses
the standard GNU tools.

> > the FHS is a nice thing, and exists for a reason.
> 
> It's well-intentioned, but it doesn't work.  Did you read
> <URL:http://cr.yp.to/slashpackage/studies.html>?

Yes, but I wasn't terribly impressed.  But then, I think that djb is a
looney-tune of the first order, so perhaps I'm biased:-)

-- 
Robert Uhl <ruhl@4dv.net>
'Those who shall sober up from the collective intoxication will have to
 admit that the Palestinians are the Jews of our era, a small, hunted
 people, defenceless, standing alone against the best weapons,
 helpless...the whole world is against them.'
                   --Ha'aretz, 13 June 1982


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Paul Jarc]

ruhl@4dv.net (Robert Uhl <ruhl@4dv.net>) wrote:
> If two seperate packages use the same name for a command,

That doesn't happen with slashpackage, because there's a global
registry for command names.  If one package is already using a certain
name, no one will be able to register it for another package.

>> With slashpackage, it's as simple as "package/install".
>
> That means a custom install script must be used--with stow, one uses
> the standard GNU tools.

I'm not sure what you mean by "custom".  The package/install script is
included in the package's tarball.  It's not something the user has to
write to install it.  It is *different* from the GNU tools, but I
don't think that's much of an obstacle.  Also, you don't always use
the GNU tools with stow.  You use whatever tools the package comes
with.


paul


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Robert Uhl <ruhl@4dv.net>]

prj@po.cwru.edu (Paul Jarc) writes:
>
> > If two seperate packages use the same name for a command,
> 
> That doesn't happen with slashpackage, because there's a global
> registry for command names.  If one package is already using a
> certain name, no one will be able to register it for another
> package.

By `package,' I mean a software package, not a slashpackage package.
That is, if one software suite uses lstr to mean `list translations,'
and another uses it to mean `last record,' then you're going to have a
collision, not matter what system you use.  In this case, it sounds as
though one cannot install both packages.  Which is perhaps an
improvement over the current method, in which one installs them and
wonders why the new package works while the old breaks.

Stow, incidentally, screams if one tries to install two things with
the same name.  Which is nice.

> > > With slashpackage, it's as simple as "package/install".
> >
> > That means a custom install script must be used--with stow, one
> > uses the standard GNU tools.
> 
> I'm not sure what you mean by `custom.'  The package/install script
> is included in the package's tarball.

It's something non-standard which someone, somewhere must write.  With
stow, I download a package and install it, whether or not that author
had any idea of me using it.  With slashpackage, if the author hasn't
provided it, I must.

> Also, you don't always use the GNU tools with stow.  You use
> whatever tools the package comes with.

Fortunately, nearly everyone uses GNU autoconf/automake, and those who
don't typically provide similar install-elsewhere functionality.  But
yes, in the last reckoning there are painful instances.

-- 
Robert Uhl <ruhl@4dv.net>
There is no place for nationalism in the Church.  All are one in
Christ.      --Blessed Martyr Philoumenos of Jacob's Well, +1979


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Paul Jarc]

ruhl@4dv.net (Robert Uhl <ruhl@4dv.net>) wrote:
> prj@po.cwru.edu (Paul Jarc) writes:
>>> If two seperate packages use the same name for a command,
>>
>> That doesn't happen with slashpackage, because there's a global
>> registry for command names.  If one package is already using a
>> certain name, no one will be able to register it for another
>> package.
>
> By `package,' I mean a software package, not a slashpackage package.

slashpackage packages are software packages.  They are not analogous
to (source or binary) .rpms or .debs - i.e., they are not sources
taken from an author and repackaged by a (different) distributor.
They *are* the source tarballs produced by the authors themselves,
laid out to work with slashpackage.

> That is, if one software suite uses lstr to mean `list translations,'
> and another uses it to mean `last record,' then you're going to have a
> collision, not matter what system you use.

Yes, I know.  I never meant to say otherwise.  But if their authors
participate in the slashpackage registry, that won't happen.  The
authors won't release packages that use names that they haven't
registered.  The benefit of collision avoidance is derived from
authors' participation, not admins'.

> Stow, incidentally, screams if one tries to install two things with
> the same name.  Which is nice.

I'm working on a slashpackage management tool that will do the same,
although it won't be necessary for packages that participate in the
registry.

>> I'm not sure what you mean by `custom.'  The package/install script
>> is included in the package's tarball.
>
> It's something non-standard which someone, somewhere must write.

There is no codified standard here, AFAIK.  There is only the
automake/autoconf de-facto *precedent* - which also has/had to be
written.  Do you think automated tools to create package/install
scripts would be any more difficult?  Offhand, I can think of three
such tools already in existence.

> With slashpackage, if the author hasn't provided it, I must.

slashpackage is not intended for you to take up where the author left
off.  The intent is that the author fully participates.

(It happens that I violate that intent on my machines and install
everything in its own directory under /package.  I've already scripted
this for hundreds of packages, so you don't have to.  For autoconf'ed
packages, it's usually just "./configure --prefix=...; make;
make install".  And just to clarify, I don't do this in the form of a
package/install script.)

> Fortunately, nearly everyone uses GNU autoconf/automake, and those who
> don't typically provide similar install-elsewhere functionality.

Yep - for example, my tool for generating package/install and related
scripts does.


paul


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Eric E Moore]

[-- Attachment #1: Type: text/plain, Size: 660 bytes --]

prj@po.cwru.edu (Paul Jarc) writes:

> Yes, I know.  I never meant to say otherwise.  But if their authors
> participate in the slashpackage registry, that won't happen.  The
> authors won't release packages that use names that they haven't
> registered.  The benefit of collision avoidance is derived from
> authors' participation, not admins'.

Of course, if you maintain a global registry of command names, that
authors participate in, then just installing everything in /usr/bin
won't ever have any collisions either.  All you've done is move the
collisions to the registry (you can't *register* a previously used
name).

-- 
Eric E. Moore

[-- Attachment #2: Type: application/pgp-signature, Size: 184 bytes --]

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

[Paul Jarc]

Eric E Moore <e.e.moore@sheffield.ac.uk> wrote:
> Of course, if you maintain a global registry of command names, that
> authors participate in, then just installing everything in /usr/bin
> won't ever have any collisions either.

Right.  It just happens that the only such registry that exists,
AFAIK, is the one for slashpackage.  The Guile maintainers could
register a package name (e.g., "prog/guile") and the command names,
even if they weren't planning to publish slashpackage-style tarballs.

> All you've done is move the collisions to the registry (you can't
> *register* a previously used name).

But since the registry is global, collisions are noticed and resolved
before the names are used, which is good.


paul


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Rob Browning]

Greg Troxel <gdt@ir.bbn.com> writes:

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

If we wanted to make the dlopened libs behave more like .scm files one
thing we might be able to do is put guile's prefix/lib dir at the
*end* of the libltdl search path briefly during a load.  This would
cause guile to fall-back to the prefix/lib whenever no envt vars are
specified (just as guile does for .scm files when GUILE_LOAD_PATH
isn't specified), but still allow overrides when appropriate.  Though
I'd need to consider this further before I could feel comfortable
recommending it.

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

This approach is fine as long as you don't want other applications and
libraries linking against your libraries (at least if you're not going
to require -R).

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Paul Jarc]

Rob Browning <rlb@defaultvalue.org> wrote:
> If we wanted to make the dlopened libs behave more like .scm files one
> thing we might be able to do is put guile's prefix/lib dir at the
> *end* of the libltdl search path briefly during a load.

If you mean at the end of LD_LIBRARY_PATH (or whatever libltdl
variable is initialized from that, but *not* other directories), then
that would match how a fixed libltdl (which searches the rpath
directories) would behave.  ld.so (on GNU/Linux, anyway) searches in
this order: LD_LIBRARY_PATH, rpath, ld.so.cache, /lib, /usr/lib.
Appending to LD_LIBRARY_PATH (or equivalent) would be a good interim
measure until libltdl is fixed.


paul


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Paul Jarc]

Greg Troxel <gdt@ir.bbn.com> wrote:
> 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.

"Tend to" is right - for ELF, it's possible to force linking to a
fixed path even with ld.so, at least if ld supports -soname.  (AFAIK
only GNU ld does.)  You can set the soname to the full path, and
that's what will be embedded in the executable and used by ld.so.
ld.so will not search the usual places in this case.  But this means
that you cannot set LD_LIBRARY_PATH to run the tests before
installing; the libraries must be installed before the program will
run at all.  So this strategy is useful only when the libraries belong
to a different, already-installed package, or when the installation
prefix is dedicated to this installation of this package so it's safe
to install before testing.

I'm not saying that Guile should do this, BTW.  Just pointing out
something I find interesting.


paul


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Thien-Thi Nguyen]

   From: Greg Troxel <gdt@ir.bbn.com>
   Date: 20 Sep 2002 08:04:22 -0400

   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.

another option is to provide "guile-config link-internal".  e.g.:

  $ guile-config link
  -L/home/ttn/local/lib -lguile -lltdl -lm

  $ guile-config link-internal
  guileqthreads
  guilereadline
  guilesrfi_13_14
  guilesrfi_4

  $ guile-config link-internal guilesrfi_13_14
  -L/home/ttn/local/lib/guile/1.4.1.89/modules -lguilesrfi_13_14

this way, the large majority of people who don't care about these
internal libraries can remain blissfully unaware of them, but yet the
necessary info is available to those who have the need.  their makefiles
would look like:

  LIBS = `guile-config link` `guile-config link-internal guilesrfi_13_14`

problem solved, everybody's happy.  in fact, i like this idea so much,
see below for a diff against scripts/guile-config that implements this
in cvs (will appear in 1.4.1.90).

thi


_________________________________________________
Index: guile-config
===================================================================
RCS file: /home/ttn/cvs/guile-core/scripts/guile-config,v
retrieving revision 1.4
diff -w -c -b -c -r1.4 guile-config
*** guile-config	1 Sep 2002 10:18:26 -0000	1.4
--- guile-config	20 Sep 2002 20:33:07 -0000
***************
*** 56,61 ****
--- 56,67 ----
  ;;   Print the linker command-line flags necessary to link against
  ;;   libguile, and any other libraries it requires.
  ;;
+ ;; * Usage: guile-config link-internal [LIB ...]
+ ;;
+ ;;   If LIB is given, print the linker command-line flags necessary
+ ;;   to link against internal libraries LIB ..., otherwise, print a list
+ ;;   of the internal libraries.
+ ;;
  ;; * Usage: guile-config compile
  ;;
  ;;   Print C compiler flags for compiling code that uses Guile.
***************
*** 99,105 ****
  
  (define *this-module* (current-module))
  
! (define *commands* '(link compile info re-prefix-info scmconfig acsubst))
  
  (define *me* "guile-config")
  
--- 105,117 ----
  
  (define *this-module* (current-module))
  
! (define *commands* '(link
!                      link-internal
!                      compile
!                      info
!                      re-prefix-info
!                      scmconfig
!                      acsubst))
  
  (define *me* "guile-config")
  
***************
*** 183,188 ****
--- 195,212 ----
              (else
               (cons (car libs) (loop (cdr libs))))))))
    (newline))
+ 
+ \f
+ ;;; the "link-internal" subcommand
+ 
+ (define (COMMAND:link-internal args)
+   (let ((m (format #f "~A/~A/modules" (GBI 'pkglibdir) (GBI 'guileversion))))
+     (if (null? args)
+         (system (format #f "cd ~A && ls *.la | sed 's/^lib//;s/.la$//'" m))
+         (begin
+           (format #t "-L~A" m)
+           (for-each (lambda (lib) (format #t " -l~A" lib)) args)
+           (format #t "\n")))))
  
  \f
  ;;; the "compile" subcommand


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Paul Jarc]

Thien-Thi Nguyen <ttn@giblet.glug.org> wrote:
> their makefiles would look like:
>
>   LIBS = `guile-config link` `guile-config link-internal guilesrfi_13_14`
>
> problem solved, everybody's happy.

I'm not.  Use of guile-config assumes that other packages should refer
to Guile's files via Guile's installation prefix.  As I explained in
<m34rclixmb.fsf@multivac.cwru.edu>, that's not always desirable.


paul


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Paul Jarc]

I wrote:
> Thien-Thi Nguyen <ttn@giblet.glug.org> wrote:
>> their makefiles would look like:
>>
>>   LIBS = `guile-config link` `guile-config link-internal guilesrfi_13_14`
>>
>> problem solved, everybody's happy.
>
> I'm not.

Although if guile-config would output, say, $GUILE_CONFIG_PREFIX, if
it's set, in place of the real instllation prefix, then I'd be happy.


paul


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Thien-Thi Nguyen]

   From: prj@po.cwru.edu (Paul Jarc)
   Date: Fri, 20 Sep 2002 17:16:30 -0400

   I'm not.  Use of guile-config assumes that other packages should refer
   to Guile's files via Guile's installation prefix.  As I explained in
   <m34rclixmb.fsf@multivac.cwru.edu>, that's not always desirable.

noted.  i think guile-config should be honest, and that any indirection
scheme your install discipline requires is your responsibility to patch.

all of this has nothing to do w/ internal vs. public libraries, however.
i see now that providing link-internal is incomplete w/o the associated
"compile-internal" which brings me back to my previous pov: *internal*
stuff should stay that way.  i'm going to remove link-internal; guess i
was swayed by the rampant fuzzy thinking...

thi


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Paul Jarc]

Thien-Thi Nguyen <ttn@giblet.glug.org> wrote:
>    From: prj@po.cwru.edu (Paul Jarc)
>    Date: Fri, 20 Sep 2002 17:16:30 -0400
>
>    I'm not.  Use of guile-config assumes that other packages should refer
>    to Guile's files via Guile's installation prefix.  As I explained in
>    <m34rclixmb.fsf@multivac.cwru.edu>, that's not always desirable.
>
> noted.  i think guile-config should be honest, and that any indirection
> scheme your install discipline requires is your responsibility to patch.

I agree that guile-config should be honest *by default*, but if I
explicitly express that I want to refer to Guile's files via a
different path than the one guile-config already knows about, why make
it any harder for me than it has to be?  It's much easier for
guile-config to output a different path than it is for me to fix it
afterwards; I would have to delve into the internals of each package
that uses guile-config.


paul


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Thien-Thi Nguyen]

   From: prj@po.cwru.edu (Paul Jarc)
   Date: Sat, 21 Sep 2002 17:51:04 -0400

   I agree that guile-config should be honest *by default*, but if I
   explicitly express that I want to refer to Guile's files via a
   different path than the one guile-config already knows about, why make
   it any harder for me than it has to be?

at the moment, i don't believe anyone is actively trying to make things
difficult for you.  i'm glad you bring up "difficulty", however.  to
take your proposal seriously i request a failure analysis: how can the
proposed mechanism be abused (perhaps unintentionally)?  what are the
remedies in those cases?  how can nested build/install/dist scenarios
fail?  how can this interact badly w/ auto* practice?  these questions
are examples to get you started; ping me if you want more.

introducing env var sensitivity is not a light step to take; many (good)
programmers will find fault w/ such action-at-a-distance behavior if we
don't do it right.  are we afraid of their criticism?  no.  do we want
to waste time later countering it?  no.  so let us flay the concept now
as if we were clueless naysayers attempting to heap FUD on a working
design.

   It's much easier for guile-config to output a different path than it
   is for me to fix it afterwards; I would have to delve into the
   internals of each package that uses guile-config.

along w/ the full (ab|mis)usage analysis (preferably texinfo but plain
text is fine, too), feel free to submit a small patch to guile-config.

thi


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Gary Houston]

> From: Greg Troxel <gdt@ir.bbn.com>
> Date: 20 Sep 2002 08:04:22 -0400

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

I think you are right about this, more or less.  I think guile should
always pass a full path when dlopening.  However, like the case for
scm files, I think Guile should have its own search path for shared
objects, i.e., an equivalent to %load-path which a user can set.

While Marius is not around, I think his argument against this is that
libguile should not take over functionality from libtool, i.e.,
libtool's "standard" searching should always be used, and any problems
should be addressed by improving libtool.  Improvents to libtool could
give benefits to other non-guile applications perhaps.

However I don't like the requirement that every module needs to be
versioned correctly, which seems unlikely to go away even if libtool
is improved.  I also don't like the idea of adding large numbers of
guile modules to standard library directories in the default
installation.

As for linking from C applications, it seems cumbersome to require
that they use -l for each module.  Only primitive Scheme procedures
can be called directly as C functions and this goes behind the back of
the module system, possibly leading to naming conflicts.  I don't
think anyone is suggesting that a Guile module would ever be linked by
an application without also linking libguile, so it seems to me that
no extra dependency is introduced if libguile mediates all access to
modules, also for C code (i.e., if you want to call a primitive module
function from C, ask libguile for a handle to it first).



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Rob Browning]

Gary Houston <ghouston@arglist.com> writes:

> However I don't like the requirement that every module needs to be
> versioned correctly, which seems unlikely to go away even if libtool
> is improved.  I also don't like the idea of adding large numbers of
> guile modules to standard library directories in the default
> installation.
>
> As for linking from C applications, it seems cumbersome to require
> that they use -l for each module.  Only primitive Scheme procedures
> can be called directly as C functions and this goes behind the back of
> the module system, possibly leading to naming conflicts.  I don't
> think anyone is suggesting that a Guile module would ever be linked by
> an application without also linking libguile, so it seems to me that
> no extra dependency is introduced if libguile mediates all access to
> modules, also for C code (i.e., if you want to call a primitive module
> function from C, ask libguile for a handle to it first).

Well, that's certainly a possiblity, but when I started working
on/thinking about the "add-on library" issue and was trying to
ascertain what features of the shared libraries were optional and what
features were required, I was told that the ability to use the public
functions provided by these libraries directly from other C
applications and libraries without any indirection was a *required*
feature.  Accordingly all my considerations and responses since have
been with that requirement in mind.

If we *did* allow a level of "patchup" (or indirection) at runtime,
such that -l linking was no longer permitted, then that would change
the design landscape substantially...

Say

  scm_c_use_module ("foo bar",
                    "bar-1", &bar_1_func,
                    "bar-2", &bar_2_func,
                    NULL);

or whatever.

*Should* we do this?  I don't know -- this is probably something
Marius needs to comment on, though as I mentioned above, in the past I
believe the answer has been "no".

On a more general note, though I won't actually be out of town for the
next two weeks like Marius, I may in fact be fairly slow on the lists.
I have some real-world items that will be keeping me very busy, and
the free time I do have I really need to spend fixing up some
languishing Debian issues, including packaging 1.6.  I also want to
finish up re-integrating my GMP bignum work into the latest CVS.

With respect to shared libraries, I'm tempted to suggest we table the
discussion until Marius can participate.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Marius Vollmer]

Gary Houston <ghouston@arglist.com> writes:

> As for linking from C applications, it seems cumbersome to require
> that they use -l for each module.  Only primitive Scheme procedures
> can be called directly as C functions [...]

I don't think this is true.  The C API can be different from the
Scheme API.  Just look at libguile itself.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Marius Vollmer]

Greg Troxel <gdt@ir.bbn.com> writes:

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

Yep, my point is that one should have a consistent system.  Guile
should find its shared libraries in the same way that other packages
might find them.  I don't think it is difficult to arrange for this.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Marius Vollmer]

Greg Troxel <gdt@ir.bbn.com> writes:

> 1) 'Shared libraries' and guile's dlopening of libguilereadline-v-12
>    are not the same thing.

Can't we make them the same?  That would simplify things, I'd say.

>    The search paths for resolving these libraries at run-time is given
>    by '-R' linker options, at least on BSD.  Thus, these libraries can
>    be found in the appropriate place at runtime without  having to set
>    environment variables.

How does dlopen behave on BSD?  Does it honor the -R linker options?
Can we do the same in ltdl_dlopen?

>    dlopening does not use this link-time binding.  (perhaps on NetBSD
>    the -R values are being used by dlopen

Could you try to find out?

> 2) On BSD ELF systems, it is my opinion that having to have set
>    LD_LIBRARY_PATH is a sign of underlying brokenness.  I have not had
>    to do this other than guile.  So it's a warning sign that guile
>    seems to require setting this variable.

I don't agree that this is a sign of brokeness.

>    I don't understand the notion of prepending $(libdir) to the search
>    path as the right answer; this will still look in other places, and
>    I think it is incorrect to even try those other places for files
>    that are part of guile.

It sounds convincing to me to do away with library searching
completely.  However, this doesn't seem to be the way the current
system works.  Debian appearantly even has a policy against using '-R'
or equivalent.

> 4) Setting LD_LIBRARY_PATH can't work in general.   If one had two
>    guile installations in /usr/guile16-{foo,bar}, one of the lib dirs
>    has to come first.  The other installation will dlopen the wrong .so
>    files.

This is not a typical situation I think.  If you need to have two
mutually incompatible hacked versions of a single Guile release on
your system, and have them active at the same time, you need to hack
one of them to use different major versions for its libraries, or
different library names.

Alternatively, you could have scripts that setup the environment for
one of the two hacked versions, like so

  $ cat with-guile-env
  #! /bin/sh
  prefix=$1; shift
  PATH=$prefix/bin:$PATH LD_LIBRARY_PATH=$prefix/lib:$LD_LIBRARY_PATH exec "$@"

that you would use as

  $ with-guile-env /usr/guile-16-foo guile
  
> 5) LD_LIBRARY_PATH doesn't work in setuid/setgid situations.  Guile
>    should not foreclose this option.

Good point.  Off hand, I would say that a setuid program should use a
Guile that works without LD_LIBRARY_PATH, for example, one installed
in /usr.

> It looks like libltdl:try_dlopen needs only to check if the first
> character is / and then not do the searching steps in order to fully
> implement the above scheme.

Yes, we should do this checking.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user