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: tomas
Subject: Re: 1.6.0 problems with libguilereadline-v-12 and fix
Date: Wed, 9 Oct 2002 08:47:32 +0200
User-agent: Mutt/1.3.24i

On Tue, Oct 08, 2002 at 11:16:56PM +0200, Marius Vollmer wrote:
> address@hidden 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




reply via email to

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