Re: cvs guile build/install problems

Re: cvs guile build/install problems

[Lynn Winebarger]

On Monday 11 March 2002 13:39, Marius Vollmer wrote:
> Lynn Winebarger <owinebar@free-expression.org> writes:
> > Saturday's cvs of guile-core:
> > Using automake 1.5, autoconf 2.52,libtool 1.4.2
> > minor
> > doc/tutorial was missing mdate-sh after configuring (chugged along 
after 
> > copying it from doc/ref).
> 
> This file should be installed by "autogen.sh".  I have automake
> 1.4-p4, and after removing doc/ref/mdate-sh, I get
> 
>     ./autogen.sh 
>     autoheader2.50: libguile/scmconfig.h.in is unchanged
>     doc/ref/Makefile.am:24: installing `doc/ref/mdate-sh'
> 
> Doesn't automake 1.5 behave the same?
        mdate-sh gets installed in doc/ref, but not in doc/tutorial.

> > doc/tutorial/version.texi - had to add an extra "@" to the CVSROOT line
> 
> I have no CVSROOT line in version.texi.  The file is created by a rule
> in doc/tutorial/version/Makefile.  Can you check what is happening?
> 
       I have to find my autoconf decoder ring, but I will try to find it 
and get back to you (on both the above).

> > less minor:
> > guile's shared libraries deposited in /usr/local/lib, but would only 
load 
> > them if they showed up in /usr/local/share/guile/1.7.0 (used symbolic 
links 
> > and it worked).
> 
> Can you elaborate?  There shouldn't be any shared libraries in
> /usr/local/share/guile/ as of 1.7.  Do you have "/usr/local/lib" in
> your LD_LIBRARY_PATH?
> 
      No.  I set my ld.so.conf to point to /usr/local/lib so shared 
libraries get loaded correctly and forget about LD_LIBRARY_PATH.  
My system mysteriously doesn't have a man page or info documentation about 
dlopen, but looking at the libtool docs tells me that the calling program 
has to provide a search function, and it appears there's no C library 
function to search ld.so.cache (and it may change from version to version 
of ld.so, so there's no way for you to use it directly).  Anyway, my 
expectation was bogus.  [ and setting LD_LIBRARY_PATH did work ]
      However, it does appear your search function still looks in 
/usr/local/share/guile/1.7.0 for shared libraries.  Wouldn't it be 
reasonably to have it search the libdir set at configure time instead or in 
addition to that directory?   
      The documentation is a little vague on the library paths - that is, 
whether "library" refers to a library of scheme code, a compiled library, 
or both [ which may vary from context to context in the docs, I'm just 
pointing out it should be made clear ].

_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: cvs guile build/install problems

[Marius Vollmer]

Lynn Winebarger <owinebar@free-expression.org> writes:

> On Monday 11 March 2002 13:39, Marius Vollmer wrote:
>  
> > This file should be installed by "autogen.sh".  I have automake
> > 1.4-p4, and after removing doc/ref/mdate-sh, I get
> > 
> >     ./autogen.sh 
> >     autoheader2.50: libguile/scmconfig.h.in is unchanged
> >     doc/ref/Makefile.am:24: installing `doc/ref/mdate-sh'
> > 
> > Doesn't automake 1.5 behave the same?
>
>         mdate-sh gets installed in doc/ref, but not in doc/tutorial.

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'

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?

> Wouldn't it be reasonably to have it search the libdir set at
> configure time instead or in addition to that directory?

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.

_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

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

_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: cvs guile build/install problems

[Lynn Winebarger]

On Thursday 28 March 2002 02:30, Lynn Winebarger wrote:
>    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.

       Actually, invoking autogen.sh twice solved all the problems I 
mentioned in my original mail (except the library loading part).  It 
even solved one I didn't realize I had - it installed guile-snarf.
       I think I've seen this type of behaviour before but I can't remember
where/when.

Lynn

_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: cvs guile build/install problems

[Lynn Winebarger]

On Thursday 28 March 2002 02:30, Lynn Winebarger wrote:
>    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.

    I think this is a bug in automake (I've tried with 1.6 as well).  It
appears to be a dependency problem involving guile-tut.texi's inclusion
of version.texi and the use of TEXINFO_TEX=../ref/texinfo.tex.  The first
run of automake puts mdate-sh in doc/ref, then texinfo.tex into doc/ref.
In the second run of automake, mdate-sh gets installed in doc/tutorial.

Maybe.  I haven't actually tracked the bug down in automake.  However, it 
looks like the Makefile.am in doc/tutorial conforms to automake's 
documentation, which would make this (by definition) a bug in automake.

One other thing I noticed - doing a diff of the guile tree after 1 and 2 invocations
of autogen.sh revealed another difference: mdate-sh and depcomp get added to 
DIST_COMMON only on the 2nd run.

Lynn

_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: cvs guile build/install problems

[Marius Vollmer]

Lynn Winebarger <owinebar@free-expression.org> writes:

> 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.

I can confirm this now.  The snapshots fall over because of this as
well.  It is a bug in automake, as far as I can see.  The workaround
for now is to invoke automake twice from autogen.sh (committed).  I'll
go and gently slap the automake guys for this.

_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: cvs guile build/install problems

[Thien-Thi Nguyen]

   From: Lynn Winebarger <owinebar@free-expression.org>
   Date: Sat, 16 Mar 2002 01:24:07 -0500

   The documentation is a little vague on the library paths - that is,
   whether "library" refers to a library of scheme code, a compiled
   library, or both [ which may vary from context to context in the
   docs, I'm just pointing out it should be made clear ].

i've add this to bug 10 (embedded libltdl masks system version
unconditionally) since fully documenting our (perhaps currently
incomplete) understanding of libltdl's expected and actual usage, is a
good idea.

thi

_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile