Re: cvs guile build/install problems

[Lynn Winebarger]

On Wednesday 20 March 2002 16:51, Marius Vollmer wrote:
> Sorry, I tested with the wrong file.  But automake will also install
> doc/tutorial/mdate-sh for me:
>
>     $ rm doc/tutorial/mdate-sh
>     $ rm doc/ref/mdate-sh
>     $ ./autogen.sh
>     autoheader2.50: libguile/scmconfig.h.in is unchanged
>     doc/ref/Makefile.am:24: installing `doc/ref/mdate-sh'
>     doc/tutorial/Makefile.am:24: installing `doc/tutorial/mdate-sh'

   I haven't tracked down the specific problem, but I can say that invoking
autogen.sh twice will install doc/tutorial/mdate-sh the second time (but not 
the first when it's right out of CVS).  It installs doc/ref/mdate-sh the first
time.   I'm making a separate copy of the directory for building.

> Could you investigate why this doesn't happen for you?
>
> >       However, it does appear your search function still looks in
> > /usr/local/share/guile/1.7.0 for shared libraries.
>
> Could you give a test case and strace or whatever so that I can try to
> reproduce this behavior?
>
    Sorry, my fault.  I must have invoked the stable guile that time because
I haven't been able to get the cvs version to find the libraries without an 
env variable set.

> Hmm, I'm not sure.  We leave all our library searching to libltdl, and
> libltdl might not have been configured with the same libdir as Guile.
> I also think that creating shared library universes that are local to
> a program will not work as well as globally configuring the shared
> library system in a consistent way.

       Maybe.  But modules aren't really the same as shared libraries - 
other programs don't need to be snooping around guile modules
and guile shouldn't be snooping in other programs' modules.
      Hypothetical situation:  A program links to guile and another interpreter,
which also uses libtool.  Both have modules named <x>.so, but they are
not the same.  However, if both rely on the LTDL_LIBRARY_PATH variable,
only one will be found and it will be the wrong one for one of the interpreters.
      Ok, it's unlikely with a disciplined naming scheme, but that's ugly.  
It's 
also probably why ltdl searches paths given by the program before searching
the paths given by the environment variables (which seemed backward to me
at first).
      It's also remotely possible that someone would write a setuid guile script
that gets passed munged environment variables where some user has set up
bogus modules.  Not terribly likely I know.  But when I have a sysadmin hat on
I always prefer being able to require dynamically loaded code come from
a known and trusted location (at least in production usage).  I'm paranoid that
way.
      But mostly I'd just like it to work without having to set environment 
variables
that I don't otherwise have to set (my LD_LIBRARY_PATH is empty - that's
what ld.so.conf is for, except in special cases).

Lynn