autohackery and nightly snapshots

autohackery and nightly snapshots

[Neil Jerram]

I finally got to the bottom of all the gettext, config.rpath, m4 and
automake nonsense that's been turning my brain to mush.  As a result,
I'm happy to report that the 1.8 snapshot is now building again, and
the HEAD snapshot is getting a lot further than it has for the last
few months.

For anyone interested...

- The automake/m4 tracing problem that complains incorrectly about
  AM_INTL_SUBDIR being missing has in fact been fixed in m4.  I had
  installed a fixed m4 in /usr/local/bin, but autom4te hardcodes
  /usr/bin/m4 (even when autom4te is itself in /usr/local/bin), so
  wasn't getting the fix.

  The solution for this is either to have a fixed m4 in /usr/bin, or
  to "export M4=/usr/local/bin/m4" before running ./autogen.sh.  Then
  the dummy definition of AM_INTL_SUBDIR in acinclude.m4 isn't needed
  (and so I've backed this out).

- config.rpath is required at autogen time, so long as the installed
  gettext is recent enough.  Older gettexts (such as on the nightly
  snapshot machine) do not enforce this, so the build on such machines
  goes past this check and appears to succeed.

  So config.rpath should be in CVS, and now is in 1.8 and HEAD branches.

- config.rpath does not need to be listed in EXTRA_DIST, however.
  So long as config.rpath is present, automake includes it in
  DIST_COMMON, which means it gets into the distribution.

(The HEAD snapshot is now failing on i18n.test when doing a "make
distcheck", because of a (load-extension "libguile-i18n-v-0" ...) call
not being able to find the library.  I suspect the solution is this:

--- pre-inst-guile.in	17 Apr 2006 00:18:11 -0000	1.8
+++ pre-inst-guile.in	21 Feb 2007 21:31:16 -0000
@@ -43,7 +43,7 @@
 # Code:
 
 # config
-subdirs_with_ltlibs="srfi guile-readline"       # maintain me
+subdirs_with_ltlibs="srfi guile-readline libguile"       # maintain me
 
 # env (set by configure)
 top_srcdir="@top_srcdir_absolute@"

but I'm still investigating.)

Regards,
     Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: autohackery and nightly snapshots

[Kevin Ryde]

Neil Jerram <neil@ossau.uklinux.net> writes:
>
> -subdirs_with_ltlibs="srfi guile-readline"       # maintain me
> +subdirs_with_ltlibs="srfi guile-readline libguile"       # maintain me

Yep, sounds right.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: autohackery and nightly snapshots

[Ludovic Courtès]

Hi,

Neil Jerram <neil@ossau.uklinux.net> writes:

> -subdirs_with_ltlibs="srfi guile-readline"       # maintain me
> +subdirs_with_ltlibs="srfi guile-readline libguile"       # maintain me

Strangely, I had noticed that `(use-modules (ice-9 i18n))' would work
with `pre-inst-guile', even before `libguile-i18n-v-0' is installed,
perhaps because of some side-effect induced by the `libguile/guile'
Libtool script.  But apparently, this is not always the case, so your
fix makes sense.

Thanks!

Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: autohackery and nightly snapshots

[Neil Jerram]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> Hi,
>
> Neil Jerram <neil@ossau.uklinux.net> writes:
>
>> -subdirs_with_ltlibs="srfi guile-readline"       # maintain me
>> +subdirs_with_ltlibs="srfi guile-readline libguile"       # maintain me
>
> Strangely, I had noticed that `(use-modules (ice-9 i18n))' would work
> with `pre-inst-guile', even before `libguile-i18n-v-0' is installed,
> perhaps because of some side-effect induced by the `libguile/guile'
> Libtool script.  But apparently, this is not always the case, so your
> fix makes sense.

Yes, I've observed that too, when running the "make distcheck" on my
own machine.  My guess is that pre-inst-guile is picking up a copy of
libguile-i18n-v-0 from somewhere else (i.e. /usr/lib or
/usr/local/lib), but I haven't got to the bottom of this yet, and
that's why I haven't yet committed the above change to CVS.

That said, I might commit the above change tonight provisionally, to
see if it helps the snapshot.

Regards,
     Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: autohackery and nightly snapshots

[Neil Jerram]

Neil Jerram <neil@ossau.uklinux.net> writes:

> ludovic.courtes@laas.fr (Ludovic Courtès) writes:
>
>> Hi,
>>
>> Neil Jerram <neil@ossau.uklinux.net> writes:
>>
>>> -subdirs_with_ltlibs="srfi guile-readline"       # maintain me
>>> +subdirs_with_ltlibs="srfi guile-readline libguile"       # maintain me
>>
>> Strangely, I had noticed that `(use-modules (ice-9 i18n))' would work
>> with `pre-inst-guile', even before `libguile-i18n-v-0' is installed,
>> perhaps because of some side-effect induced by the `libguile/guile'
>> Libtool script.  But apparently, this is not always the case, so your
>> fix makes sense.
>
> Yes, I've observed that too, when running the "make distcheck" on my
> own machine.  My guess is that pre-inst-guile is picking up a copy of
> libguile-i18n-v-0 from somewhere else (i.e. /usr/lib or
> /usr/local/lib), but I haven't got to the bottom of this yet, and
> that's why I haven't yet committed the above change to CVS.
>
> That said, I might commit the above change tonight provisionally, to
> see if it helps the snapshot.

I noticed from strace (below) that, on my machine, ltdl tries to open
libguile-i18n-v-0.so from libguile/.libs, once it has failed with the
locations in LTDL_LIBRARY_PATH.  I'm guessing that this is a piece of
fallback "try to open .so in the same directory as the running
executable" logic, and that this logic wasn't present in some older
version of libtool.  (Although there is nothing in libtool's NEWS or
doc to support this.)

For tonight, therefore, I've committed the pre-inst-guile.in change,
and also some code in autogen.sh to display the versions of libtool et
al.  We'll see what that gives.

Regards,
     Neil

open("/home/neil/guile-cvs-head/guile/guile-core/guile-readline/libguile-i18n-v-0.la", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/neil/guile-cvs-head/guile/guile-core/srfi/libguile-i18n-v-0.la", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/libguile-i18n-v-0.la", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/libguile-i18n-v-0.la", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/i486-linuxlibc1/lib/libguile-i18n-v-0.la", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/X11R6/lib/libguile-i18n-v-0.la", O_RDONLY) = -1 ENOENT (No such file or directory)
open("libguile-i18n-v-0.la", O_RDONLY)  = -1 ENOENT (No such file or directory)
access("/home/neil/guile-cvs-head/guile/guile-core/guile-readline/libguile-i18n-v-0.so", R_OK) = -1 ENOENT (No such file or directory)
access("/home/neil/guile-cvs-head/guile/guile-core/srfi/libguile-i18n-v-0.so", R_OK) = -1 ENOENT (No such file or directory)
access("/lib/libguile-i18n-v-0.so", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/libguile-i18n-v-0.so", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/i486-linuxlibc1/lib/libguile-i18n-v-0.so", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/X11R6/lib/libguile-i18n-v-0.so", R_OK) = -1 ENOENT (No such file or directory)
futex(0x402c41b4, FUTEX_WAKE, 2147483647) = 0
open("/home/neil/guile-cvs-head/guile/guile-core/libguile/.libs/libguile-i18n-v-0.so", O_RDONLY) = 8



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: autohackery and nightly snapshots

[Kevin Ryde]

Neil Jerram <neil@ossau.uklinux.net> writes:
>
> I noticed from strace (below) that, on my machine, ltdl tries to open
> libguile-i18n-v-0.so from libguile/.libs, once it has failed with the
> locations in LTDL_LIBRARY_PATH.  I'm guessing that this is a piece of
> fallback "try to open .so in the same directory as the running
> executable" logic, and that this logic wasn't present in some older
> version of libtool.  (Although there is nothing in libtool's NEWS or
> doc to support this.)

There's a comment that it tries the name as given, like just "foo.la"
etc.  Probably not what you normally want :(.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: autohackery and nightly snapshots

[Neil Jerram]

Kevin Ryde <user42@zip.com.au> writes:

> Neil Jerram <neil@ossau.uklinux.net> writes:
>>
>> I noticed from strace (below) that, on my machine, ltdl tries to open
>> libguile-i18n-v-0.so from libguile/.libs, once it has failed with the
>> locations in LTDL_LIBRARY_PATH.  I'm guessing that this is a piece of
>> fallback "try to open .so in the same directory as the running
>> executable" logic, and that this logic wasn't present in some older
>> version of libtool.  (Although there is nothing in libtool's NEWS or
>> doc to support this.)
>
> There's a comment that it tries the name as given, like just "foo.la"
> etc.  Probably not what you normally want :(.

Where are you seeing that, in the manual or in the libltdl code?



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: autohackery and nightly snapshots

[Kevin Ryde]

Neil Jerram <neil@ossau.uklinux.net> writes:
>
> Where are you seeing that, in the manual or in the libltdl code?

The ltdl.c code, in try_dlopen,

      /* Now try to open the .la file.  If there is no directory name
         component, try to find it first in user_search_path and then other
         prescribed paths.  Otherwise (or in any case if the module was not
         yet found) try opening just the module name as passed.  */

The code looks like what it says is true (without actually running it
...)


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel