* 1.6.0 problems with libguilereadline-v-12 and fix @ 2002-09-18 20:33 Greg Troxel 2002-09-18 21:14 ` Marius Vollmer 0 siblings, 1 reply; 80+ messages in thread From: Greg Troxel @ 2002-09-18 20:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-18 20:33 1.6.0 problems with libguilereadline-v-12 and fix Greg Troxel @ 2002-09-18 21:14 ` Marius Vollmer 2002-09-18 21:53 ` Paul Jarc ` (2 more replies) 0 siblings, 3 replies; 80+ messages in thread From: Marius Vollmer @ 2002-09-18 21:14 UTC (permalink / raw) Cc: guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-18 21:14 ` Marius Vollmer @ 2002-09-18 21:53 ` Paul Jarc 2002-09-18 22:40 ` Rob Browning 2002-10-03 15:38 ` Marius Vollmer 2002-09-19 13:17 ` Arno Peters 2002-09-19 13:43 ` Greg Troxel 2 siblings, 2 replies; 80+ messages in thread From: Paul Jarc @ 2002-09-18 21:53 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-18 21:53 ` Paul Jarc @ 2002-09-18 22:40 ` Rob Browning 2002-09-18 22:43 ` Paul Jarc 2002-10-03 15:38 ` Marius Vollmer 1 sibling, 1 reply; 80+ messages in thread From: Rob Browning @ 2002-09-18 22:40 UTC (permalink / raw) Cc: guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-18 22:40 ` Rob Browning @ 2002-09-18 22:43 ` Paul Jarc 2002-09-19 3:22 ` Rob Browning 2002-09-19 4:02 ` Thien-Thi Nguyen 0 siblings, 2 replies; 80+ messages in thread From: Paul Jarc @ 2002-09-18 22:43 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-18 22:43 ` Paul Jarc @ 2002-09-19 3:22 ` Rob Browning 2002-09-19 4:13 ` Robert Uhl <ruhl@4dv.net> ` (4 more replies) 2002-09-19 4:02 ` Thien-Thi Nguyen 1 sibling, 5 replies; 80+ messages in thread From: Rob Browning @ 2002-09-19 3:22 UTC (permalink / raw) Cc: guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-19 3:22 ` Rob Browning @ 2002-09-19 4:13 ` Robert Uhl <ruhl@4dv.net> 2002-09-19 10:03 ` rm ` (3 subsequent siblings) 4 siblings, 0 replies; 80+ messages in thread From: Robert Uhl <ruhl@4dv.net> @ 2002-09-19 4:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-19 3:22 ` Rob Browning 2002-09-19 4:13 ` Robert Uhl <ruhl@4dv.net> @ 2002-09-19 10:03 ` rm 2002-09-19 15:02 ` Rob Browning 2002-10-03 15:56 ` Marius Vollmer 2002-09-19 10:11 ` rm ` (2 subsequent siblings) 4 siblings, 2 replies; 80+ messages in thread From: rm @ 2002-09-19 10:03 UTC (permalink / raw) Cc: Greg Troxel, guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-19 10:03 ` rm @ 2002-09-19 15:02 ` Rob Browning 2002-09-19 15:18 ` Paul Jarc 2002-09-19 15:27 ` rm 2002-10-03 15:56 ` Marius Vollmer 1 sibling, 2 replies; 80+ messages in thread From: Rob Browning @ 2002-09-19 15:02 UTC (permalink / raw) Cc: Greg Troxel, guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-19 15:02 ` Rob Browning @ 2002-09-19 15:18 ` Paul Jarc 2002-09-19 15:27 ` rm 1 sibling, 0 replies; 80+ messages in thread From: Paul Jarc @ 2002-09-19 15:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-19 15:02 ` Rob Browning 2002-09-19 15:18 ` Paul Jarc @ 2002-09-19 15:27 ` rm 2002-09-19 18:29 ` Rob Browning 2002-10-03 16:03 ` Marius Vollmer 1 sibling, 2 replies; 80+ messages in thread From: rm @ 2002-09-19 15:27 UTC (permalink / raw) Cc: rm, Greg Troxel, guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-19 15:27 ` rm @ 2002-09-19 18:29 ` Rob Browning 2002-10-03 16:03 ` Marius Vollmer 1 sibling, 0 replies; 80+ messages in thread From: Rob Browning @ 2002-09-19 18:29 UTC (permalink / raw) Cc: Greg Troxel, guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-19 15:27 ` rm 2002-09-19 18:29 ` Rob Browning @ 2002-10-03 16:03 ` Marius Vollmer 1 sibling, 0 replies; 80+ messages in thread From: Marius Vollmer @ 2002-10-03 16:03 UTC (permalink / raw) Cc: guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-19 10:03 ` rm 2002-09-19 15:02 ` Rob Browning @ 2002-10-03 15:56 ` Marius Vollmer 2002-10-03 17:22 ` Paul Jarc 2002-10-03 19:19 ` tomas 1 sibling, 2 replies; 80+ messages in thread From: Marius Vollmer @ 2002-10-03 15:56 UTC (permalink / raw) Cc: Rob Browning, Greg Troxel, guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-10-03 15:56 ` Marius Vollmer @ 2002-10-03 17:22 ` Paul Jarc 2002-10-04 11:58 ` Marius Vollmer 2002-10-03 19:19 ` tomas 1 sibling, 1 reply; 80+ messages in thread From: Paul Jarc @ 2002-10-03 17:22 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-10-03 17:22 ` Paul Jarc @ 2002-10-04 11:58 ` Marius Vollmer 0 siblings, 0 replies; 80+ messages in thread From: Marius Vollmer @ 2002-10-04 11:58 UTC (permalink / raw) Cc: guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-10-03 15:56 ` Marius Vollmer 2002-10-03 17:22 ` Paul Jarc @ 2002-10-03 19:19 ` tomas 2002-10-04 12:04 ` Marius Vollmer 1 sibling, 1 reply; 80+ messages in thread From: tomas @ 2002-10-03 19:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-10-03 19:19 ` tomas @ 2002-10-04 12:04 ` Marius Vollmer 2002-10-04 13:04 ` rm 0 siblings, 1 reply; 80+ messages in thread From: Marius Vollmer @ 2002-10-04 12:04 UTC (permalink / raw) Cc: guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-10-04 12:04 ` Marius Vollmer @ 2002-10-04 13:04 ` rm 2002-10-08 21:16 ` Marius Vollmer 0 siblings, 1 reply; 80+ messages in thread From: rm @ 2002-10-04 13:04 UTC (permalink / raw) Cc: tomas, guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-10-04 13:04 ` rm @ 2002-10-08 21:16 ` Marius Vollmer 2002-10-08 21:54 ` Dale P. Smith 2002-10-09 6:47 ` tomas 0 siblings, 2 replies; 80+ messages in thread From: Marius Vollmer @ 2002-10-08 21:16 UTC (permalink / raw) Cc: tomas, guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-10-08 21:16 ` Marius Vollmer @ 2002-10-08 21:54 ` Dale P. Smith 2002-10-09 6:47 ` tomas 1 sibling, 0 replies; 80+ messages in thread From: Dale P. Smith @ 2002-10-08 21:54 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-10-08 21:16 ` Marius Vollmer 2002-10-08 21:54 ` Dale P. Smith @ 2002-10-09 6:47 ` tomas 1 sibling, 0 replies; 80+ messages in thread From: tomas @ 2002-10-09 6:47 UTC (permalink / raw) Cc: rm, tomas, guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-19 3:22 ` Rob Browning 2002-09-19 4:13 ` Robert Uhl <ruhl@4dv.net> 2002-09-19 10:03 ` rm @ 2002-09-19 10:11 ` rm 2002-09-19 15:10 ` Paul Jarc 2002-09-19 21:21 ` Neil Jerram 4 siblings, 0 replies; 80+ messages in thread From: rm @ 2002-09-19 10:11 UTC (permalink / raw) Cc: Greg Troxel, guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-19 3:22 ` Rob Browning ` (2 preceding siblings ...) 2002-09-19 10:11 ` rm @ 2002-09-19 15:10 ` Paul Jarc 2002-09-19 21:21 ` Neil Jerram 4 siblings, 0 replies; 80+ messages in thread From: Paul Jarc @ 2002-09-19 15:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-19 3:22 ` Rob Browning ` (3 preceding siblings ...) 2002-09-19 15:10 ` Paul Jarc @ 2002-09-19 21:21 ` Neil Jerram 2002-09-19 22:06 ` Rob Browning 4 siblings, 1 reply; 80+ messages in thread From: Neil Jerram @ 2002-09-19 21:21 UTC (permalink / raw) Cc: Greg Troxel, guile-user >>>>> "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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-19 21:21 ` Neil Jerram @ 2002-09-19 22:06 ` Rob Browning 2002-09-19 22:17 ` Paul Jarc 0 siblings, 1 reply; 80+ messages in thread From: Rob Browning @ 2002-09-19 22:06 UTC (permalink / raw) Cc: Greg Troxel, guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-19 22:06 ` Rob Browning @ 2002-09-19 22:17 ` Paul Jarc 2002-09-19 23:13 ` Rob Browning 0 siblings, 1 reply; 80+ messages in thread From: Paul Jarc @ 2002-09-19 22:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-19 22:17 ` Paul Jarc @ 2002-09-19 23:13 ` Rob Browning 0 siblings, 0 replies; 80+ messages in thread From: Rob Browning @ 2002-09-19 23:13 UTC (permalink / raw) Cc: guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-18 22:43 ` Paul Jarc 2002-09-19 3:22 ` Rob Browning @ 2002-09-19 4:02 ` Thien-Thi Nguyen 2002-09-19 16:17 ` Paul Jarc 1 sibling, 1 reply; 80+ messages in thread From: Thien-Thi Nguyen @ 2002-09-19 4:02 UTC (permalink / raw) Cc: gdt, guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-19 4:02 ` Thien-Thi Nguyen @ 2002-09-19 16:17 ` Paul Jarc 2002-09-19 18:52 ` Thien-Thi Nguyen 0 siblings, 1 reply; 80+ messages in thread From: Paul Jarc @ 2002-09-19 16:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-19 16:17 ` Paul Jarc @ 2002-09-19 18:52 ` Thien-Thi Nguyen 2002-09-19 19:33 ` Paul Jarc 0 siblings, 1 reply; 80+ messages in thread From: Thien-Thi Nguyen @ 2002-09-19 18:52 UTC (permalink / raw) Cc: gdt, guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-19 18:52 ` Thien-Thi Nguyen @ 2002-09-19 19:33 ` Paul Jarc 2002-09-19 19:58 ` Thien-Thi Nguyen 0 siblings, 1 reply; 80+ messages in thread From: Paul Jarc @ 2002-09-19 19:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-19 19:33 ` Paul Jarc @ 2002-09-19 19:58 ` Thien-Thi Nguyen 2002-09-19 22:17 ` Thien-Thi Nguyen 0 siblings, 1 reply; 80+ messages in thread From: Thien-Thi Nguyen @ 2002-09-19 19:58 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-19 19:58 ` Thien-Thi Nguyen @ 2002-09-19 22:17 ` Thien-Thi Nguyen 2002-09-20 1:28 ` Thien-Thi Nguyen 0 siblings, 1 reply; 80+ messages in thread From: Thien-Thi Nguyen @ 2002-09-19 22:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-19 22:17 ` Thien-Thi Nguyen @ 2002-09-20 1:28 ` Thien-Thi Nguyen 2002-09-20 15:45 ` Paul Jarc 0 siblings, 1 reply; 80+ messages in thread From: Thien-Thi Nguyen @ 2002-09-20 1:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-20 1:28 ` Thien-Thi Nguyen @ 2002-09-20 15:45 ` Paul Jarc 0 siblings, 0 replies; 80+ messages in thread From: Paul Jarc @ 2002-09-20 15:45 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-18 21:53 ` Paul Jarc 2002-09-18 22:40 ` Rob Browning @ 2002-10-03 15:38 ` Marius Vollmer 2002-10-04 16:43 ` Paul Jarc 1 sibling, 1 reply; 80+ messages in thread From: Marius Vollmer @ 2002-10-03 15:38 UTC (permalink / raw) Cc: guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-10-03 15:38 ` Marius Vollmer @ 2002-10-04 16:43 ` Paul Jarc 2002-10-08 21:26 ` Marius Vollmer 0 siblings, 1 reply; 80+ messages in thread From: Paul Jarc @ 2002-10-04 16:43 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-10-04 16:43 ` Paul Jarc @ 2002-10-08 21:26 ` Marius Vollmer 2002-10-08 21:38 ` Paul Jarc 0 siblings, 1 reply; 80+ messages in thread From: Marius Vollmer @ 2002-10-08 21:26 UTC (permalink / raw) Cc: guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-10-08 21:26 ` Marius Vollmer @ 2002-10-08 21:38 ` Paul Jarc 2002-10-08 22:47 ` Marius Vollmer 0 siblings, 1 reply; 80+ messages in thread From: Paul Jarc @ 2002-10-08 21:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-10-08 21:38 ` Paul Jarc @ 2002-10-08 22:47 ` Marius Vollmer 2002-10-09 4:34 ` Paul Jarc 2002-10-09 6:51 ` tomas 0 siblings, 2 replies; 80+ messages in thread From: Marius Vollmer @ 2002-10-08 22:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-10-08 22:47 ` Marius Vollmer @ 2002-10-09 4:34 ` Paul Jarc 2002-10-09 6:51 ` tomas 1 sibling, 0 replies; 80+ messages in thread From: Paul Jarc @ 2002-10-09 4:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-10-08 22:47 ` Marius Vollmer 2002-10-09 4:34 ` Paul Jarc @ 2002-10-09 6:51 ` tomas 1 sibling, 0 replies; 80+ messages in thread From: tomas @ 2002-10-09 6:51 UTC (permalink / raw) Cc: guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-18 21:14 ` Marius Vollmer 2002-09-18 21:53 ` Paul Jarc @ 2002-09-19 13:17 ` Arno Peters 2002-09-19 14:07 ` Rob Browning 2002-10-03 16:06 ` Marius Vollmer 2002-09-19 13:43 ` Greg Troxel 2 siblings, 2 replies; 80+ messages in thread From: Arno Peters @ 2002-09-19 13:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-19 13:17 ` Arno Peters @ 2002-09-19 14:07 ` Rob Browning 2002-10-03 16:06 ` Marius Vollmer 1 sibling, 0 replies; 80+ messages in thread From: Rob Browning @ 2002-09-19 14:07 UTC (permalink / raw) Cc: guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-19 13:17 ` Arno Peters 2002-09-19 14:07 ` Rob Browning @ 2002-10-03 16:06 ` Marius Vollmer 2002-10-03 19:44 ` Rob Browning 1 sibling, 1 reply; 80+ messages in thread From: Marius Vollmer @ 2002-10-03 16:06 UTC (permalink / raw) Cc: guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-10-03 16:06 ` Marius Vollmer @ 2002-10-03 19:44 ` Rob Browning 0 siblings, 0 replies; 80+ messages in thread From: Rob Browning @ 2002-10-03 19:44 UTC (permalink / raw) Cc: Arno Peters, guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-18 21:14 ` Marius Vollmer 2002-09-18 21:53 ` Paul Jarc 2002-09-19 13:17 ` Arno Peters @ 2002-09-19 13:43 ` Greg Troxel 2002-09-19 14:53 ` Rob Browning 2002-10-03 17:37 ` Marius Vollmer 2 siblings, 2 replies; 80+ messages in thread From: Greg Troxel @ 2002-09-19 13:43 UTC (permalink / raw) Cc: guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-19 13:43 ` Greg Troxel @ 2002-09-19 14:53 ` Rob Browning 2002-09-19 15:57 ` Paul Jarc ` (2 more replies) 2002-10-03 17:37 ` Marius Vollmer 1 sibling, 3 replies; 80+ messages in thread From: Rob Browning @ 2002-09-19 14:53 UTC (permalink / raw) Cc: Marius Vollmer, guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-19 14:53 ` Rob Browning @ 2002-09-19 15:57 ` Paul Jarc 2002-09-19 18:47 ` Rob Browning 2002-09-20 11:47 ` Greg Troxel 2002-09-20 12:04 ` Greg Troxel 2 siblings, 1 reply; 80+ messages in thread From: Paul Jarc @ 2002-09-19 15:57 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-19 15:57 ` Paul Jarc @ 2002-09-19 18:47 ` Rob Browning 2002-09-19 19:32 ` Paul Jarc 0 siblings, 1 reply; 80+ messages in thread From: Rob Browning @ 2002-09-19 18:47 UTC (permalink / raw) Cc: guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-19 18:47 ` Rob Browning @ 2002-09-19 19:32 ` Paul Jarc 2002-09-19 21:07 ` Rob Browning 0 siblings, 1 reply; 80+ messages in thread From: Paul Jarc @ 2002-09-19 19:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-19 19:32 ` Paul Jarc @ 2002-09-19 21:07 ` Rob Browning 0 siblings, 0 replies; 80+ messages in thread From: Rob Browning @ 2002-09-19 21:07 UTC (permalink / raw) Cc: guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-19 14:53 ` Rob Browning 2002-09-19 15:57 ` Paul Jarc @ 2002-09-20 11:47 ` Greg Troxel 2002-09-20 12:04 ` Greg Troxel 2 siblings, 0 replies; 80+ messages in thread From: Greg Troxel @ 2002-09-20 11:47 UTC (permalink / raw) Cc: guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-19 14:53 ` Rob Browning 2002-09-19 15:57 ` Paul Jarc 2002-09-20 11:47 ` Greg Troxel @ 2002-09-20 12:04 ` Greg Troxel 2002-09-20 15:23 ` Rob Browning ` (5 more replies) 2 siblings, 6 replies; 80+ messages in thread From: Greg Troxel @ 2002-09-20 12:04 UTC (permalink / raw) Cc: guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-20 12:04 ` Greg Troxel @ 2002-09-20 15:23 ` Rob Browning 2002-09-20 22:47 ` Paul Jarc 2002-09-20 17:59 ` Rob Browning ` (4 subsequent siblings) 5 siblings, 1 reply; 80+ messages in thread From: Rob Browning @ 2002-09-20 15:23 UTC (permalink / raw) Cc: guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-20 15:23 ` Rob Browning @ 2002-09-20 22:47 ` Paul Jarc 2002-09-21 3:00 ` Rob Browning 2002-09-21 15:46 ` Robert Uhl <ruhl@4dv.net> 0 siblings, 2 replies; 80+ messages in thread From: Paul Jarc @ 2002-09-20 22:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-20 22:47 ` Paul Jarc @ 2002-09-21 3:00 ` Rob Browning 2002-09-21 15:46 ` Robert Uhl <ruhl@4dv.net> 1 sibling, 0 replies; 80+ messages in thread From: Rob Browning @ 2002-09-21 3:00 UTC (permalink / raw) Cc: guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-20 22:47 ` Paul Jarc 2002-09-21 3:00 ` Rob Browning @ 2002-09-21 15:46 ` Robert Uhl <ruhl@4dv.net> 2002-09-21 21:45 ` Paul Jarc 1 sibling, 1 reply; 80+ messages in thread From: Robert Uhl <ruhl@4dv.net> @ 2002-09-21 15:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-21 15:46 ` Robert Uhl <ruhl@4dv.net> @ 2002-09-21 21:45 ` Paul Jarc 2002-09-23 4:35 ` Robert Uhl <ruhl@4dv.net> 0 siblings, 1 reply; 80+ messages in thread From: Paul Jarc @ 2002-09-21 21:45 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-21 21:45 ` Paul Jarc @ 2002-09-23 4:35 ` Robert Uhl <ruhl@4dv.net> 2002-09-23 15:47 ` Paul Jarc 0 siblings, 1 reply; 80+ messages in thread From: Robert Uhl <ruhl@4dv.net> @ 2002-09-23 4:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-23 4:35 ` Robert Uhl <ruhl@4dv.net> @ 2002-09-23 15:47 ` Paul Jarc 2002-09-23 19:20 ` Robert Uhl <ruhl@4dv.net> 0 siblings, 1 reply; 80+ messages in thread From: Paul Jarc @ 2002-09-23 15:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-23 15:47 ` Paul Jarc @ 2002-09-23 19:20 ` Robert Uhl <ruhl@4dv.net> 2002-09-23 20:06 ` Paul Jarc 0 siblings, 1 reply; 80+ messages in thread From: Robert Uhl <ruhl@4dv.net> @ 2002-09-23 19:20 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-23 19:20 ` Robert Uhl <ruhl@4dv.net> @ 2002-09-23 20:06 ` Paul Jarc 2002-09-23 21:29 ` Eric E Moore 0 siblings, 1 reply; 80+ messages in thread From: Paul Jarc @ 2002-09-23 20:06 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-23 20:06 ` Paul Jarc @ 2002-09-23 21:29 ` Eric E Moore 2002-09-23 21:37 ` Paul Jarc 0 siblings, 1 reply; 80+ messages in thread From: Eric E Moore @ 2002-09-23 21:29 UTC (permalink / raw) [-- 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 --] ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-23 21:29 ` Eric E Moore @ 2002-09-23 21:37 ` Paul Jarc 0 siblings, 0 replies; 80+ messages in thread From: Paul Jarc @ 2002-09-23 21:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-20 12:04 ` Greg Troxel 2002-09-20 15:23 ` Rob Browning @ 2002-09-20 17:59 ` Rob Browning 2002-09-20 21:32 ` Paul Jarc 2002-09-20 20:27 ` Paul Jarc ` (3 subsequent siblings) 5 siblings, 1 reply; 80+ messages in thread From: Rob Browning @ 2002-09-20 17:59 UTC (permalink / raw) Cc: guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-20 17:59 ` Rob Browning @ 2002-09-20 21:32 ` Paul Jarc 0 siblings, 0 replies; 80+ messages in thread From: Paul Jarc @ 2002-09-20 21:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-20 12:04 ` Greg Troxel 2002-09-20 15:23 ` Rob Browning 2002-09-20 17:59 ` Rob Browning @ 2002-09-20 20:27 ` Paul Jarc 2002-09-20 20:42 ` Thien-Thi Nguyen ` (2 subsequent siblings) 5 siblings, 0 replies; 80+ messages in thread From: Paul Jarc @ 2002-09-20 20:27 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-20 12:04 ` Greg Troxel ` (2 preceding siblings ...) 2002-09-20 20:27 ` Paul Jarc @ 2002-09-20 20:42 ` Thien-Thi Nguyen 2002-09-20 21:16 ` Paul Jarc 2002-09-22 18:52 ` Gary Houston 2002-10-03 17:51 ` Marius Vollmer 5 siblings, 1 reply; 80+ messages in thread From: Thien-Thi Nguyen @ 2002-09-20 20:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-20 20:42 ` Thien-Thi Nguyen @ 2002-09-20 21:16 ` Paul Jarc 2002-09-20 21:43 ` Paul Jarc 2002-09-21 1:56 ` Thien-Thi Nguyen 0 siblings, 2 replies; 80+ messages in thread From: Paul Jarc @ 2002-09-20 21:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-20 21:16 ` Paul Jarc @ 2002-09-20 21:43 ` Paul Jarc 2002-09-21 1:56 ` Thien-Thi Nguyen 1 sibling, 0 replies; 80+ messages in thread From: Paul Jarc @ 2002-09-20 21:43 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-20 21:16 ` Paul Jarc 2002-09-20 21:43 ` Paul Jarc @ 2002-09-21 1:56 ` Thien-Thi Nguyen 2002-09-21 21:51 ` Paul Jarc 1 sibling, 1 reply; 80+ messages in thread From: Thien-Thi Nguyen @ 2002-09-21 1:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-21 1:56 ` Thien-Thi Nguyen @ 2002-09-21 21:51 ` Paul Jarc 2002-09-25 6:09 ` Thien-Thi Nguyen 0 siblings, 1 reply; 80+ messages in thread From: Paul Jarc @ 2002-09-21 21:51 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-21 21:51 ` Paul Jarc @ 2002-09-25 6:09 ` Thien-Thi Nguyen 0 siblings, 0 replies; 80+ messages in thread From: Thien-Thi Nguyen @ 2002-09-25 6:09 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-20 12:04 ` Greg Troxel ` (3 preceding siblings ...) 2002-09-20 20:42 ` Thien-Thi Nguyen @ 2002-09-22 18:52 ` Gary Houston 2002-09-23 1:50 ` Rob Browning 2002-10-03 16:33 ` Marius Vollmer 2002-10-03 17:51 ` Marius Vollmer 5 siblings, 2 replies; 80+ messages in thread From: Gary Houston @ 2002-09-22 18:52 UTC (permalink / raw) Cc: rlb, guile-user > 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-22 18:52 ` Gary Houston @ 2002-09-23 1:50 ` Rob Browning 2002-10-03 16:33 ` Marius Vollmer 1 sibling, 0 replies; 80+ messages in thread From: Rob Browning @ 2002-09-23 1:50 UTC (permalink / raw) Cc: gdt, guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-22 18:52 ` Gary Houston 2002-09-23 1:50 ` Rob Browning @ 2002-10-03 16:33 ` Marius Vollmer 1 sibling, 0 replies; 80+ messages in thread From: Marius Vollmer @ 2002-10-03 16:33 UTC (permalink / raw) Cc: gdt, rlb, guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-20 12:04 ` Greg Troxel ` (4 preceding siblings ...) 2002-09-22 18:52 ` Gary Houston @ 2002-10-03 17:51 ` Marius Vollmer 5 siblings, 0 replies; 80+ messages in thread From: Marius Vollmer @ 2002-10-03 17:51 UTC (permalink / raw) Cc: Rob Browning, guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 1.6.0 problems with libguilereadline-v-12 and fix 2002-09-19 13:43 ` Greg Troxel 2002-09-19 14:53 ` Rob Browning @ 2002-10-03 17:37 ` Marius Vollmer 1 sibling, 0 replies; 80+ messages in thread From: Marius Vollmer @ 2002-10-03 17:37 UTC (permalink / raw) Cc: guile-user 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
end of thread, other threads:[~2002-10-09 6:51 UTC | newest] Thread overview: 80+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2002-09-18 20:33 1.6.0 problems with libguilereadline-v-12 and fix Greg Troxel 2002-09-18 21:14 ` Marius Vollmer 2002-09-18 21:53 ` Paul Jarc 2002-09-18 22:40 ` Rob Browning 2002-09-18 22:43 ` Paul Jarc 2002-09-19 3:22 ` Rob Browning 2002-09-19 4:13 ` Robert Uhl <ruhl@4dv.net> 2002-09-19 10:03 ` rm 2002-09-19 15:02 ` Rob Browning 2002-09-19 15:18 ` Paul Jarc 2002-09-19 15:27 ` rm 2002-09-19 18:29 ` Rob Browning 2002-10-03 16:03 ` Marius Vollmer 2002-10-03 15:56 ` Marius Vollmer 2002-10-03 17:22 ` Paul Jarc 2002-10-04 11:58 ` Marius Vollmer 2002-10-03 19:19 ` tomas 2002-10-04 12:04 ` Marius Vollmer 2002-10-04 13:04 ` rm 2002-10-08 21:16 ` Marius Vollmer 2002-10-08 21:54 ` Dale P. Smith 2002-10-09 6:47 ` tomas 2002-09-19 10:11 ` rm 2002-09-19 15:10 ` Paul Jarc 2002-09-19 21:21 ` Neil Jerram 2002-09-19 22:06 ` Rob Browning 2002-09-19 22:17 ` Paul Jarc 2002-09-19 23:13 ` Rob Browning 2002-09-19 4:02 ` Thien-Thi Nguyen 2002-09-19 16:17 ` Paul Jarc 2002-09-19 18:52 ` Thien-Thi Nguyen 2002-09-19 19:33 ` Paul Jarc 2002-09-19 19:58 ` Thien-Thi Nguyen 2002-09-19 22:17 ` Thien-Thi Nguyen 2002-09-20 1:28 ` Thien-Thi Nguyen 2002-09-20 15:45 ` Paul Jarc 2002-10-03 15:38 ` Marius Vollmer 2002-10-04 16:43 ` Paul Jarc 2002-10-08 21:26 ` Marius Vollmer 2002-10-08 21:38 ` Paul Jarc 2002-10-08 22:47 ` Marius Vollmer 2002-10-09 4:34 ` Paul Jarc 2002-10-09 6:51 ` tomas 2002-09-19 13:17 ` Arno Peters 2002-09-19 14:07 ` Rob Browning 2002-10-03 16:06 ` Marius Vollmer 2002-10-03 19:44 ` Rob Browning 2002-09-19 13:43 ` Greg Troxel 2002-09-19 14:53 ` Rob Browning 2002-09-19 15:57 ` Paul Jarc 2002-09-19 18:47 ` Rob Browning 2002-09-19 19:32 ` Paul Jarc 2002-09-19 21:07 ` Rob Browning 2002-09-20 11:47 ` Greg Troxel 2002-09-20 12:04 ` Greg Troxel 2002-09-20 15:23 ` Rob Browning 2002-09-20 22:47 ` Paul Jarc 2002-09-21 3:00 ` Rob Browning 2002-09-21 15:46 ` Robert Uhl <ruhl@4dv.net> 2002-09-21 21:45 ` Paul Jarc 2002-09-23 4:35 ` Robert Uhl <ruhl@4dv.net> 2002-09-23 15:47 ` Paul Jarc 2002-09-23 19:20 ` Robert Uhl <ruhl@4dv.net> 2002-09-23 20:06 ` Paul Jarc 2002-09-23 21:29 ` Eric E Moore 2002-09-23 21:37 ` Paul Jarc 2002-09-20 17:59 ` Rob Browning 2002-09-20 21:32 ` Paul Jarc 2002-09-20 20:27 ` Paul Jarc 2002-09-20 20:42 ` Thien-Thi Nguyen 2002-09-20 21:16 ` Paul Jarc 2002-09-20 21:43 ` Paul Jarc 2002-09-21 1:56 ` Thien-Thi Nguyen 2002-09-21 21:51 ` Paul Jarc 2002-09-25 6:09 ` Thien-Thi Nguyen 2002-09-22 18:52 ` Gary Houston 2002-09-23 1:50 ` Rob Browning 2002-10-03 16:33 ` Marius Vollmer 2002-10-03 17:51 ` Marius Vollmer 2002-10-03 17:37 ` Marius Vollmer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).