Re: cvs guile build/install problems

* Re: cvs guile build/install problems
       [not found] ` <87lmcz54pm.fsf@zagadka.ping.de>
@ 2002-03-16  6:24   ` Lynn Winebarger
  2002-03-20 21:51     ` Marius Vollmer
  2002-03-26  3:02     ` Thien-Thi Nguyen
  0 siblings, 2 replies; 7+ messages in thread
From: Lynn Winebarger @ 2002-03-16  6:24 UTC (permalink / raw)
  Cc: bug-guile

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


^ permalink raw reply	[flat|nested] 7+ messages in thread