* autohackery and nightly snapshots
@ 2007-02-21 21:32 Neil Jerram
2007-02-21 23:03 ` Kevin Ryde
2007-02-22 9:32 ` Ludovic Courtès
0 siblings, 2 replies; 8+ messages in thread
From: Neil Jerram @ 2007-02-21 21:32 UTC (permalink / raw)
To: Guile Development
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
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: autohackery and nightly snapshots 2007-02-21 21:32 autohackery and nightly snapshots Neil Jerram @ 2007-02-21 23:03 ` Kevin Ryde 2007-02-22 9:32 ` Ludovic Courtès 1 sibling, 0 replies; 8+ messages in thread From: Kevin Ryde @ 2007-02-21 23:03 UTC (permalink / raw) To: Neil Jerram; +Cc: Guile Development 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: autohackery and nightly snapshots 2007-02-21 21:32 autohackery and nightly snapshots Neil Jerram 2007-02-21 23:03 ` Kevin Ryde @ 2007-02-22 9:32 ` Ludovic Courtès 2007-02-22 19:24 ` Neil Jerram 1 sibling, 1 reply; 8+ messages in thread From: Ludovic Courtès @ 2007-02-22 9:32 UTC (permalink / raw) To: Neil Jerram; +Cc: Guile Development 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: autohackery and nightly snapshots 2007-02-22 9:32 ` Ludovic Courtès @ 2007-02-22 19:24 ` Neil Jerram 2007-02-24 22:45 ` Neil Jerram 0 siblings, 1 reply; 8+ messages in thread From: Neil Jerram @ 2007-02-22 19:24 UTC (permalink / raw) To: Guile Development 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: autohackery and nightly snapshots 2007-02-22 19:24 ` Neil Jerram @ 2007-02-24 22:45 ` Neil Jerram 2007-02-25 22:43 ` Kevin Ryde 0 siblings, 1 reply; 8+ messages in thread From: Neil Jerram @ 2007-02-24 22:45 UTC (permalink / raw) To: Guile Development 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: autohackery and nightly snapshots 2007-02-24 22:45 ` Neil Jerram @ 2007-02-25 22:43 ` Kevin Ryde 2007-02-26 20:15 ` Neil Jerram 0 siblings, 1 reply; 8+ messages in thread From: Kevin Ryde @ 2007-02-25 22:43 UTC (permalink / raw) To: Neil Jerram; +Cc: Guile Development 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: autohackery and nightly snapshots 2007-02-25 22:43 ` Kevin Ryde @ 2007-02-26 20:15 ` Neil Jerram 2007-02-26 22:28 ` Kevin Ryde 0 siblings, 1 reply; 8+ messages in thread From: Neil Jerram @ 2007-02-26 20:15 UTC (permalink / raw) To: Guile Development 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: autohackery and nightly snapshots 2007-02-26 20:15 ` Neil Jerram @ 2007-02-26 22:28 ` Kevin Ryde 0 siblings, 0 replies; 8+ messages in thread From: Kevin Ryde @ 2007-02-26 22:28 UTC (permalink / raw) To: Neil Jerram; +Cc: Guile Development 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2007-02-26 22:28 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-02-21 21:32 autohackery and nightly snapshots Neil Jerram 2007-02-21 23:03 ` Kevin Ryde 2007-02-22 9:32 ` Ludovic Courtès 2007-02-22 19:24 ` Neil Jerram 2007-02-24 22:45 ` Neil Jerram 2007-02-25 22:43 ` Kevin Ryde 2007-02-26 20:15 ` Neil Jerram 2007-02-26 22:28 ` Kevin Ryde
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).