[Top][All Lists]
[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
- Re: 1.6.0 problems with libguilereadline-v-12 and fix, (continued)
Re: 1.6.0 problems with libguilereadline-v-12 and fix, Marius Vollmer, 2002/10/03
Re: 1.6.0 problems with libguilereadline-v-12 and fix, Marius Vollmer, 2002/10/03
Re: 1.6.0 problems with libguilereadline-v-12 and fix, Marius Vollmer, 2002/10/03
Re: 1.6.0 problems with libguilereadline-v-12 and fix, Marius Vollmer, 2002/10/03
Re: 1.6.0 problems with libguilereadline-v-12 and fix, Marius Vollmer, 2002/10/03
Re: 1.6.0 problems with libguilereadline-v-12 and fix, Marius Vollmer, 2002/10/03