guile-user
[Top][All Lists]
Advanced

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

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


From: Marius Vollmer
Subject: Re: 1.6.0 problems with libguilereadline-v-12 and fix
Date: 08 Oct 2002 23:16:56 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

address@hidden writes:

> On Fri, Oct 04, 2002 at 02:04:40PM +0200, Marius Vollmer wrote:
> > address@hidden 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




reply via email to

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