You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Justin Erenkrantz <je...@apache.org> on 2009/03/11 18:08:39 UTC
Note regarding --disable-static on trunk
If you use --disable-static on trunk right now and try to run svn
binary, you may end up with a binary that segfaults.
However, I don't think I'm going to have cycles in the immediate term
to create a patch for this. I'll try to find time during ApacheCon in
a few weeks to fix if no one beats me to it. (If any of you are in
the Amsterdam area, please stop by! I know Greg and I will both be
there.)
The fix is to build the libraries with '-shared' flag, but the svn
binary should *not* have the '-shared' flag when it is linked. IOW,
the libraries to be linked with one set of LDFLAGS (that has '-shared'
set) and the binaries need another set of LDFLAGS that does *not* have
'-shared' set. We'll need to add some magic to gen-make and friends
to add this alternative linking flag for binaries and then teach
configure to set the flags correctly.
(The other short-term fix is to use jlibtool of course!)
I hope this help points someone in the right direction to create a
patch. =) -- justin
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1308869
Re: Note regarding --disable-static on trunk
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Mar 11, 2009 at 11:08:39AM -0700, Justin Erenkrantz wrote:
> If you use --disable-static on trunk right now and try to run svn
> binary, you may end up with a binary that segfaults.
>
> However, I don't think I'm going to have cycles in the immediate term
> to create a patch for this. I'll try to find time during ApacheCon in
> a few weeks to fix if no one beats me to it. (If any of you are in
> the Amsterdam area, please stop by! I know Greg and I will both be
> there.)
>
> The fix is to build the libraries with '-shared' flag, but the svn
> binary should *not* have the '-shared' flag when it is linked. IOW,
> the libraries to be linked with one set of LDFLAGS (that has '-shared'
> set) and the binaries need another set of LDFLAGS that does *not* have
> '-shared' set. We'll need to add some magic to gen-make and friends
> to add this alternative linking flag for binaries and then teach
> configure to set the flags correctly.
>
> (The other short-term fix is to use jlibtool of course!)
>
> I hope this help points someone in the right direction to create a
> patch. =) -- justin
>
*argh* libtool headache *argh*
Re: Note regarding --disable-static on trunk
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Mar 23, 2009 at 12:02:09PM +0000, Stefan Sperling wrote:
> On Wed, Mar 11, 2009 at 11:08:39AM -0700, Justin Erenkrantz wrote:
> > If you use --disable-static on trunk right now and try to run svn
> > binary, you may end up with a binary that segfaults.
>
> So my trunk build is now unusable. I will try jlibtool as a short-term
> fix, but would greatly appreciate a fix that makes things work out of
> the box again. After all, we still claim to support GNU libtool, so
> this problem is a real regression.
Well, jlibtool does not work for me.
After applying this patch to make it build:
--- build/jlibtool.c.orig Mon Mar 23 12:08:48 2009
+++ build/jlibtool.c Mon Mar 23 12:09:03 2009
@@ -75,7 +75,7 @@
# define LD_LIBRARY_PATH "DYLD_LIBRARY_PATH"
#endif
-#if defined(__linux__) || defined(__FreeBSD__) || defined(__NetBSD__)
+#if defined(__linux__) || defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__)
# define SHELL_CMD "/bin/sh"
# define DYNAMIC_LIB_EXT "so"
# define MODULE_LIB_EXT "so"
... building apr-util fails like this:
/home/stsp/svn/objdir/apr-1.3.3/libtool --silent --mode=link gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -pthread -L/usr/local/lib -release 1 -module -rpath /home/stsp/svn/prefix/apr/lib/apr-util-1 -o dbd/apr_dbd_pgsql.la dbd/apr_dbd_pgsql.lo -L/usr/local/lib -lpq
gcc: 1: No such file or directory
*** Error code 1
I have no idea how to fix it.
I can't do any svn development now.
I don't want to have to remove packages provided by the OS.
Can you please help me to get my build working again?
Thanks,
Stefan
Re: Note regarding --disable-static on trunk
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Mar 23, 2009 at 04:34:03PM +0000, Stefan Sperling wrote:
> On Mon, Mar 23, 2009 at 12:02:09PM +0000, Stefan Sperling wrote:
> > Now, my svn binary suddenly is a dynamically linked one, and picks up
> > APR from /usr/local/lib at runtime (this is where the APR version
> > provided by the operating system's package manager is living).
> > It is using tons of wrong shared libs, not the ones I want it to use
> > (e.g. sqlite and neon are also wrong, it's not just APR).
>
> > This seems to be the reason for crashes like this one:
>
> Justin, I just read back in the thread and saw that you already
> described a fix in English, and asked for a patch. I will [have to]
> tackle to fix this as soon as I am going to do some coding on svn
> again. But it would of course be much more convenient for me if the
> problem was fixed before then.
I can now build trunk again with --disable-shared.
My problem was fixed by not using the libtool script that ships with
the APR tarball, but using the usual system-wide libtool script instead.
(Can be done by running ./buildconf in the apr source tree.)
Stefan
Re: Note regarding --disable-static on trunk
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Mar 23, 2009 at 12:02:09PM +0000, Stefan Sperling wrote:
> Now, my svn binary suddenly is a dynamically linked one, and picks up
> APR from /usr/local/lib at runtime (this is where the APR version
> provided by the operating system's package manager is living).
> It is using tons of wrong shared libs, not the ones I want it to use
> (e.g. sqlite and neon are also wrong, it's not just APR).
> This seems to be the reason for crashes like this one:
Justin, I just read back in the thread and saw that you already
described a fix in English, and asked for a patch. I will [have to]
tackle to fix this as soon as I am going to do some coding on svn
again. But it would of course be much more convenient for me if the
problem was fixed before then.
Another note for clarity:
My self-compiled APR is 1.3.3.
The OS-provided one is 1.2.11.
The crashing code is #ifdef'd for 1.3.0 and upwards:
* N.B. If we have APR 1.3+, we can unbuffer the file to let us use mmap
* and zero-copy the PUT body. However, on older APR versions, we can't
* check the buffer status; but serf will fall through and create a file
* bucket for us on the buffered svndiff handle.
*/
apr_file_flush(ctx->svndiff);
#if APR_VERSION_AT_LEAST(1, 3, 0)
apr_file_buffer_set(ctx->svndiff, NULL, 0);
#endif
At compile time the compiler sees APR 1.3.3, but at run time
1.2.11 is loaded. Hence the crash.
Stefan
> GNU gdb 6.3
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "i386-unknown-openbsd4.5"...
> Core was generated by `svn'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /usr/lib/libpthread.so.11.1...done.
> Loaded symbols for /usr/lib/libpthread.so.11.1
> Reading symbols from /usr/local/lib/libsasl2.so.2.22...done.
> Loaded symbols for /usr/local/lib/libsasl2.so.2.22
> Reading symbols from /home/stsp/svn/prefix/serf/lib/libserf-0.so.0.0...done.
> Loaded symbols for /home/stsp/svn/prefix/serf/lib/libserf-0.so.0.0
> Reading symbols from /usr/local/lib/libaprutil-1.so.2.11...done.
> Loaded symbols for /usr/local/lib/libaprutil-1.so.2.11
> Reading symbols from /usr/local/lib/libapr-1.so.3.0...done.
> Loaded symbols for /usr/local/lib/libapr-1.so.3.0
> Reading symbols from /usr/local/lib/libsqlite3.so.13.0...done.
> Loaded symbols for /usr/local/lib/libsqlite3.so.13.0
> Reading symbols from /usr/local/lib/libdb.so.5.0...done.
> Loaded symbols for /usr/local/lib/libdb.so.5.0
> Symbols already loaded for /usr/lib/libpthread.so.11.1
> Reading symbols from /usr/local/lib/libneon.so.27.0...done.
> Loaded symbols for /usr/local/lib/libneon.so.27.0
> Reading symbols from /usr/lib/libasn1.so.16.0...done.
> Loaded symbols for /usr/lib/libasn1.so.16.0
> Reading symbols from /usr/lib/libkrb5.so.16.0...done.
> Loaded symbols for /usr/lib/libkrb5.so.16.0
> Reading symbols from /usr/lib/libgssapi.so.5.0...done.
> Loaded symbols for /usr/lib/libgssapi.so.5.0
> Reading symbols from /usr/local/lib/libiconv.so.5.0...done.
> Loaded symbols for /usr/local/lib/libiconv.so.5.0
> Reading symbols from /usr/local/lib/libintl.so.4.0...done.
> Loaded symbols for /usr/local/lib/libintl.so.4.0
> Reading symbols from /usr/lib/libssl.so.14.0...done.
> Loaded symbols for /usr/lib/libssl.so.14.0
> Reading symbols from /usr/lib/libcrypto.so.17.0...done.
> Loaded symbols for /usr/lib/libcrypto.so.17.0
> Reading symbols from /usr/lib/libz.so.4.1...done.
> Loaded symbols for /usr/lib/libz.so.4.1
> Reading symbols from /usr/lib/libexpat.so.9.0...done.
> Loaded symbols for /usr/lib/libexpat.so.9.0
> Reading symbols from /usr/lib/libc.so.50.1...done.
> Loaded symbols for /usr/lib/libc.so.50.1
> Reading symbols from /usr/libexec/ld.so...done.
> Loaded symbols for /usr/libexec/ld.so
> #0 pthread_mutex_lock (mutex=0x706d7433)
> at /usr/src/lib/libpthread/uthread/uthread_mutex.c:674
> 674 else if ((*mutex != NULL) || ((ret = init_static(mutex)) == 0))
> (gdb) bt
> #0 pthread_mutex_lock (mutex=0x706d7433)
> at /usr/src/lib/libpthread/uthread/uthread_mutex.c:674
> #1 0x1c13c945 in apr_file_buffer_set (file=0x896010b0,
> buffer=0x16 <Address 0x16 out of bounds>, bufsize=0)
> at /home/stsp/svn/src/apr-1.3.3/file_io/unix/buffer.c:34
> #2 0x1c104496 in create_put_body (baton=0x82e7fcd0, alloc=0x80dc9050,
> pool=0x80dc9018) at subversion/libsvn_ra_serf/commit.c:786
> #3 0x1c10066f in setup_request (request=0x7f8cd0a0, setup_baton=0x8641d348,
> req_bkt=0x7f8cd0ac, acceptor=0x7f8cd0b8, acceptor_baton=0x7f8cd0bc,
> handler=0x7f8cd0c0, handler_baton=0x7f8cd0c4, pool=0x80dc9018)
> at subversion/libsvn_ra_serf/util.c:1311
> #4 0x00ef0e5f in write_to_connection ()
> from /home/stsp/svn/prefix/serf/lib/libserf-0.so.0.0
> #5 0x00ef137d in process_connection ()
> from /home/stsp/svn/prefix/serf/lib/libserf-0.so.0.0
> #6 0x00ef1695 in serf_event_trigger ()
> from /home/stsp/svn/prefix/serf/lib/libserf-0.so.0.0
> #7 0x00ef1746 in serf_context_run ()
> from /home/stsp/svn/prefix/serf/lib/libserf-0.so.0.0
> #8 0x1c0ff34c in svn_ra_serf__context_run_wait (done=0x8641d398,
> sess=0x87aae8f8, pool=0x8899b018) at subversion/libsvn_ra_serf/util.c:539
> #9 0x1c10659e in close_file (file_baton=0x82e7fcd0,
> text_checksum=0x8641d320 "4a6af6406870dd13fb81047cedf462c1",
> pool=0x8899b018) at subversion/libsvn_ra_serf/commit.c:1913
> #10 0x1c04b96d in svn_wc_transmit_text_deltas2 (tempfile=0xcfbe4998,
> digest=0xcfbe49f0 "Jjö@hpÝ\023û\201\004|íôbÁ«\200(\230\030",
> path=0x81b7a150 "/home/stsp/svn/svn-trunk/www/svn_1.6_releasenotes.html",
> adm_access=0x7decb360, fulltext=0, editor=0x81274f28,
> file_baton=0x82e7fcd0, pool=0x8899b018)
> at subversion/libsvn_wc/adm_crawler.c:1013
> #11 0x1c021db9 in svn_client__do_commit (
> base_url=0x87aae6f0 "https://svn.collab.net/repos/svn/trunk/www",
> commit_items=0x81b7a0f0, adm_access=0x89338250, editor=0x81274f28,
> edit_baton=0x81274cf8,
> notify_path_prefix=0x8946a938 "/home/stsp/svn/svn-trunk",
> tempfiles=0xcfbe4ae8, checksums=0xcfbe4ae4, ctx=0x7c5c2940,
> pool=0x7c5c2018) at subversion/libsvn_client/commit_util.c:1659
> #12 0x1c01f3ac in svn_client_commit4 (commit_info_p=0xcfbe4b74,
> targets=0x82b83738, depth=svn_depth_infinity, keep_locks=0,
> keep_changelists=0, changelists=0x7c5c21f8, revprop_table=0x0,
> ctx=0x7c5c2940, pool=0x7c5c2018) at subversion/libsvn_client/commit.c:1669
> #13 0x1c008033 in svn_cl__commit (os=0x7c5c21b8, baton=0xcfbe4c60,
> pool=0x7c5c2018) at subversion/svn/commit-cmd.c:112
> #14 0x1c00fc8d in main (argc=2, argv=0xcfbe4e44) at subversion/svn/main.c:2099
Re: Note regarding --disable-static on trunk
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Mar 11, 2009 at 11:08:39AM -0700, Justin Erenkrantz wrote:
> If you use --disable-static on trunk right now and try to run svn
> binary, you may end up with a binary that segfaults.
I think I ran into a related problem.
It looks like --disable-shared is also broken.
I run configure like this:
./configure --enable-maintainer-mode \
--disable-shared \
--with-ssl \
--prefix="$(SVN_PREFIX)" \
--with-apr="$(PREFIX)/apr" \
--with-apr-util="$(PREFIX)/apr" \
--with-neon="$(PREFIX)/neon" \
--with-serf="$(PREFIX)/serf" \
--with-sqlite="$(PREFIX)/sqlite"
Where $(PREFIX) points to /home/stsp/svn/prefix.
I compile all dependencies with debug symbols so that I can get
proper traces from crashes inside these libraries.
I compile statically because otherwise the build fails because
of libtool (see http://svn.haxx.se/dev/archive-2007-12/0145.shtml).
Now, my svn binary suddenly is a dynamically linked one, and picks up
APR from /usr/local/lib at runtime (this is where the APR version
provided by the operating system's package manager is living).
It is using tons of wrong shared libs, not the ones I want it to use
(e.g. sqlite and neon are also wrong, it's not just APR).
This is with a trunk build from today:
$ ldd `which svn`
/home/stsp/svn/prefix/svn-trunk/bin/svn:
Start End Type Open Ref GrpRef Name
1c000000 3c04f000 exe 1 0 0 /home/stsp/svn/prefix/svn-trunk/bin/svn
04e97000 24e9d000 rlib 0 1 0 /usr/local/lib/libsasl2.so.2.22
0690e000 26912000 rlib 0 1 0 /home/stsp/svn/prefix/serf/lib/libserf-0.so.0.0
00ada000 20ade000 rlib 0 2 0 /usr/local/lib/libaprutil-1.so.2.11
05e29000 25e2e000 rlib 0 3 0 /usr/local/lib/libapr-1.so.3.0
02ade000 22aeb000 rlib 0 1 0 /usr/local/lib/libsqlite3.so.13.0
005f5000 20610000 rlib 0 3 0 /usr/local/lib/libdb.so.5.0
0dfab000 2dfb4000 rlib 0 1 0 /usr/lib/libpthread.so.11.1
08862000 28869000 rlib 0 1 0 /usr/local/lib/libneon.so.27.0
00131000 20141000 rlib 0 2 0 /usr/lib/libasn1.so.16.0
09105000 29115000 rlib 0 2 0 /usr/lib/libkrb5.so.16.0
018d6000 218db000 rlib 0 2 0 /usr/lib/libgssapi.so.5.0
0b912000 2b9f1000 rlib 0 4 0 /usr/local/lib/libiconv.so.5.0
03ee5000 23ee9000 rlib 0 2 0 /usr/local/lib/libintl.so.4.0
02649000 22656000 rlib 0 3 0 /usr/lib/libssl.so.14.0
0af54000 2af94000 rlib 0 3 0 /usr/lib/libcrypto.so.17.0
0ede8000 2edf0000 rlib 0 3 0 /usr/lib/libz.so.4.1
0a46f000 2a478000 rlib 0 4 0 /usr/lib/libexpat.so.9.0
0aae3000 2ab1c000 rlib 0 1 0 /usr/lib/libc.so.50.1
02472000 02472000 rtld 0 1 0 /usr/libexec/ld.so
This seems to be the reason for crashes like this one:
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-openbsd4.5"...
Core was generated by `svn'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libpthread.so.11.1...done.
Loaded symbols for /usr/lib/libpthread.so.11.1
Reading symbols from /usr/local/lib/libsasl2.so.2.22...done.
Loaded symbols for /usr/local/lib/libsasl2.so.2.22
Reading symbols from /home/stsp/svn/prefix/serf/lib/libserf-0.so.0.0...done.
Loaded symbols for /home/stsp/svn/prefix/serf/lib/libserf-0.so.0.0
Reading symbols from /usr/local/lib/libaprutil-1.so.2.11...done.
Loaded symbols for /usr/local/lib/libaprutil-1.so.2.11
Reading symbols from /usr/local/lib/libapr-1.so.3.0...done.
Loaded symbols for /usr/local/lib/libapr-1.so.3.0
Reading symbols from /usr/local/lib/libsqlite3.so.13.0...done.
Loaded symbols for /usr/local/lib/libsqlite3.so.13.0
Reading symbols from /usr/local/lib/libdb.so.5.0...done.
Loaded symbols for /usr/local/lib/libdb.so.5.0
Symbols already loaded for /usr/lib/libpthread.so.11.1
Reading symbols from /usr/local/lib/libneon.so.27.0...done.
Loaded symbols for /usr/local/lib/libneon.so.27.0
Reading symbols from /usr/lib/libasn1.so.16.0...done.
Loaded symbols for /usr/lib/libasn1.so.16.0
Reading symbols from /usr/lib/libkrb5.so.16.0...done.
Loaded symbols for /usr/lib/libkrb5.so.16.0
Reading symbols from /usr/lib/libgssapi.so.5.0...done.
Loaded symbols for /usr/lib/libgssapi.so.5.0
Reading symbols from /usr/local/lib/libiconv.so.5.0...done.
Loaded symbols for /usr/local/lib/libiconv.so.5.0
Reading symbols from /usr/local/lib/libintl.so.4.0...done.
Loaded symbols for /usr/local/lib/libintl.so.4.0
Reading symbols from /usr/lib/libssl.so.14.0...done.
Loaded symbols for /usr/lib/libssl.so.14.0
Reading symbols from /usr/lib/libcrypto.so.17.0...done.
Loaded symbols for /usr/lib/libcrypto.so.17.0
Reading symbols from /usr/lib/libz.so.4.1...done.
Loaded symbols for /usr/lib/libz.so.4.1
Reading symbols from /usr/lib/libexpat.so.9.0...done.
Loaded symbols for /usr/lib/libexpat.so.9.0
Reading symbols from /usr/lib/libc.so.50.1...done.
Loaded symbols for /usr/lib/libc.so.50.1
Reading symbols from /usr/libexec/ld.so...done.
Loaded symbols for /usr/libexec/ld.so
#0 pthread_mutex_lock (mutex=0x706d7433)
at /usr/src/lib/libpthread/uthread/uthread_mutex.c:674
674 else if ((*mutex != NULL) || ((ret = init_static(mutex)) == 0))
(gdb) bt
#0 pthread_mutex_lock (mutex=0x706d7433)
at /usr/src/lib/libpthread/uthread/uthread_mutex.c:674
#1 0x1c13c945 in apr_file_buffer_set (file=0x896010b0,
buffer=0x16 <Address 0x16 out of bounds>, bufsize=0)
at /home/stsp/svn/src/apr-1.3.3/file_io/unix/buffer.c:34
#2 0x1c104496 in create_put_body (baton=0x82e7fcd0, alloc=0x80dc9050,
pool=0x80dc9018) at subversion/libsvn_ra_serf/commit.c:786
#3 0x1c10066f in setup_request (request=0x7f8cd0a0, setup_baton=0x8641d348,
req_bkt=0x7f8cd0ac, acceptor=0x7f8cd0b8, acceptor_baton=0x7f8cd0bc,
handler=0x7f8cd0c0, handler_baton=0x7f8cd0c4, pool=0x80dc9018)
at subversion/libsvn_ra_serf/util.c:1311
#4 0x00ef0e5f in write_to_connection ()
from /home/stsp/svn/prefix/serf/lib/libserf-0.so.0.0
#5 0x00ef137d in process_connection ()
from /home/stsp/svn/prefix/serf/lib/libserf-0.so.0.0
#6 0x00ef1695 in serf_event_trigger ()
from /home/stsp/svn/prefix/serf/lib/libserf-0.so.0.0
#7 0x00ef1746 in serf_context_run ()
from /home/stsp/svn/prefix/serf/lib/libserf-0.so.0.0
#8 0x1c0ff34c in svn_ra_serf__context_run_wait (done=0x8641d398,
sess=0x87aae8f8, pool=0x8899b018) at subversion/libsvn_ra_serf/util.c:539
#9 0x1c10659e in close_file (file_baton=0x82e7fcd0,
text_checksum=0x8641d320 "4a6af6406870dd13fb81047cedf462c1",
pool=0x8899b018) at subversion/libsvn_ra_serf/commit.c:1913
#10 0x1c04b96d in svn_wc_transmit_text_deltas2 (tempfile=0xcfbe4998,
digest=0xcfbe49f0 "Jjö@hpÝ\023û\201\004|íôbÁ«\200(\230\030",
path=0x81b7a150 "/home/stsp/svn/svn-trunk/www/svn_1.6_releasenotes.html",
adm_access=0x7decb360, fulltext=0, editor=0x81274f28,
file_baton=0x82e7fcd0, pool=0x8899b018)
at subversion/libsvn_wc/adm_crawler.c:1013
#11 0x1c021db9 in svn_client__do_commit (
base_url=0x87aae6f0 "https://svn.collab.net/repos/svn/trunk/www",
commit_items=0x81b7a0f0, adm_access=0x89338250, editor=0x81274f28,
edit_baton=0x81274cf8,
notify_path_prefix=0x8946a938 "/home/stsp/svn/svn-trunk",
tempfiles=0xcfbe4ae8, checksums=0xcfbe4ae4, ctx=0x7c5c2940,
pool=0x7c5c2018) at subversion/libsvn_client/commit_util.c:1659
#12 0x1c01f3ac in svn_client_commit4 (commit_info_p=0xcfbe4b74,
targets=0x82b83738, depth=svn_depth_infinity, keep_locks=0,
keep_changelists=0, changelists=0x7c5c21f8, revprop_table=0x0,
ctx=0x7c5c2940, pool=0x7c5c2018) at subversion/libsvn_client/commit.c:1669
#13 0x1c008033 in svn_cl__commit (os=0x7c5c21b8, baton=0xcfbe4c60,
pool=0x7c5c2018) at subversion/svn/commit-cmd.c:112
#14 0x1c00fc8d in main (argc=2, argv=0xcfbe4e44) at subversion/svn/main.c:2099
The libtool installed by APR is:
$ ~/svn/prefix/apr/build-1/libtool --version
ltmain.sh (GNU libtool) 1.5.26 (1.1220.2.492 2008/01/30 06:40:56)
So my trunk build is now unusable. I will try jlibtool as a short-term
fix, but would greatly appreciate a fix that makes things work out of
the box again. After all, we still claim to support GNU libtool, so
this problem is a real regression.
Thanks,
Stefan