You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@collab.net> on 2001/07/02 16:19:09 UTC
libtool 1.4 problem
A friend of ours has discovered a compatibility problem between
the latest libtool (1.4) and our build system.
I was able to reproduce the problem myself. Here's what I did:
* virgin RedHat 7.0 system
* built & installed db3.2.9 and libtool 1.4
* checked out subversion, apr, neon.
* ./autogen && ./configure --enable-maintainer-mode --disable-shared
When I run `make`, I get errors linking the svn binary:
=======================================================================
cd subversion/clients/cmdline && /bin/sh /home/sussman/projects/subversion/libtool --silent --mode=link gcc -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -g -Wall -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -pthread -Wpointer-arith -Wwrite-strings -Wshadow -DSVN_DEBUG -DAP_DEBUG -I./subversion/include -I. -I./apr/include -I./neon/src -I./expat-lite -I/usr/local/BerkeleyDB.3.2/include -rpath /usr/local/lib -o svn add-cmd.o checkout-cmd.o commit-cmd.o delete-cmd.o diff-cmd.o diff.o feedback.o help-cmd.o import-cmd.o main.o propget-cmd.o proplist-cmd.o props.o propset-cmd.o status-cmd.o status.o trace-commit.o trace-update.o update-cmd.o util.o ../../../subversion/libsvn_client/libsvn_client.la ../../../subversion/libsvn_wc/libsvn_wc.la ../../../subversion/libsvn_ra/libsvn_ra.la ../../../subversion/libsvn_delta/libsvn_delta.la ../../../subversion/libsvn_subr/libsvn_subr.la /home/sussman/projects/subversion/apr/libapr.la /home/su!
ssman/projects/subversion/apr/shmem/unix/mm/libmm.la ../../../expat-lite/libexpat.la -lm -lcrypt -lnsl -ldl
gcc: /home/sussman/projects/subversion/subversion/libsvn_ra_dav/.libs/.libs/libsvn_ra_dav.a: No such file or directory
gcc: /home/sussman/projects/subversion/neon/src/.libs/.libs/libneon.a: No such file or directory
gcc: /home/sussman/projects/subversion/subversion/libsvn_ra_local/.libs/.libs/libsvn_ra_local.a: No such file or directory
gcc: /home/sussman/projects/subversion/subversion/libsvn_delta/.libs/.libs/libsvn_delta.a: No such file or directory
gcc: /home/sussman/projects/subversion/subversion/libsvn_subr/.libs/.libs/libsvn_subr.a: No such file or directory
gcc: /home/sussman/projects/subversion/subversion/libsvn_repos/.libs/.libs/libsvn_repos.a: No such file or directory
gcc: /home/sussman/projects/subversion/subversion/libsvn_fs/.libs/.libs/libsvn_fs.a: No such file or directory
make: *** [subversion/clients/cmdline/svn] Error 1
=======================================================================
Our friend theorizes that the new libtool is somehow confused by our
non-recursive make system. I don't know enough to diagnose. Anyone
have a definitive analysis of the problem?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: libtool 1.4 problem
Posted by Karl Fogel <kf...@collab.net>.
Jon Trowbridge <tr...@ximian.com> writes:
> I think (though I haven't tried it yet) that the install problem can be
> worked around by tweaking install.sh. Since it is just a small script,
> and since the change that needs to be made is sort of annoying, I'd
> suggest just copying it from apr/build and creating a subversion-specific
> install.sh.
>
> But I haven't had a time to test this out yet, so there may still be more
> problems with a libtool 1.4 build even after the install.sh thing is worked
> out. I'll report to the list when more details become available.
Okay, thanks.
For now, let's hold off and stick with libtool 1.3.5, until we know we
can make the 1.4 experience friendly for everyone.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: libtool 1.4 problem
Posted by Jon Trowbridge <tr...@ximian.com>.
On 02 Jul 2001 16:11:49 -0500, Karl Fogel wrote:
> I think requiring 1.4 is fine, as long as we're sure we can build
> Subversion under it. Jon and Ben have confirmed that we can, using
> Jon's patch (is that right, guys?).
Not quite. My patch fixes the compile, but not the install.
> If so, let's apply the patch, but also tweak autogen.sh or something
> to look for libtool 1.4 and complain (with URL) if it can't find it,
> so people are led along the upgrade path conveniently.
>
> Ben points out that APR does check for a libtool 1.3.3 or newer, which
> both 1.3.5 and 1.4 will satisfy. However, Jon's patch included a
> patch to APR's install.sh. Is that part of the patch *required* for
> us to switch Subversion to 1.4, or can we just apply the Subversion
> portions of the patch and take up the APR portion with the APR dev
> list separately?
I think (though I haven't tried it yet) that the install problem can be
worked around by tweaking install.sh. Since it is just a small script,
and since the change that needs to be made is sort of annoying, I'd
suggest just copying it from apr/build and creating a subversion-specific
install.sh.
But I haven't had a time to test this out yet, so there may still be more
problems with a libtool 1.4 build even after the install.sh thing is worked
out. I'll report to the list when more details become available.
-JT
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: libtool 1.4 problem
Posted by Karl Fogel <kf...@collab.net>.
Joe Orton <jo...@btconnect.com> writes:
> IIRC the .libs thing was to get inter-library dependencies working:
> something that libtool 1.3 doesn't support but 1.4 does (I think in
> theory the build can be simplified further by requiring 1.4, not that I
> am advocating that position since I'm hand-waving)
I think requiring 1.4 is fine, as long as we're sure we can build
Subversion under it. Jon and Ben have confirmed that we can, using
Jon's patch (is that right, guys?).
If so, let's apply the patch, but also tweak autogen.sh or something
to look for libtool 1.4 and complain (with URL) if it can't find it,
so people are led along the upgrade path conveniently.
Ben points out that APR does check for a libtool 1.3.3 or newer, which
both 1.3.5 and 1.4 will satisfy. However, Jon's patch included a
patch to APR's install.sh. Is that part of the patch *required* for
us to switch Subversion to 1.4, or can we just apply the Subversion
portions of the patch and take up the APR portion with the APR dev
list separately?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: libtool 1.4 problem
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Jul 02, 2001 at 09:39:19PM +0100, Joe Orton wrote:
> On Mon, Jul 02, 2001 at 07:21:01PM +0100, Tim Waugh wrote:
> > On Mon, Jul 02, 2001 at 12:09:05PM -0500, Ben Collins-Sussman wrote:
> > > So your patch looks like it's basically removing ".libs" wherever it
> > > can from build system paths. Obviously, Greg Stein didn't put those
> > > in there extraneously -- so I assume your patch will *break* the build
> > > for libtool 1.3.5, right?
> >
> > I'm pretty sure this isn't the case. I have seen similar problems
> > with another package (openjade): the .libs is superfluous. It's a
> > libtool-internal thing, and shouldn't need to be explicitly
> > referenced.
>
> IIRC the .libs thing was to get inter-library dependencies working:
> something that libtool 1.3 doesn't support but 1.4 does (I think in
> theory the build can be simplified further by requiring 1.4, not that I
> am advocating that position since I'm hand-waving)
Joe is on the money here. The explicit use of ".libs" was to reach into the
directory to reference the .a or .so files and link against them explicitly.
There was no way to use the .la file because of the broken interdependency
stuff.
IMO, requiring libtool 1.4 is a fine idea.
I haven't read my Apache mail for over two weeks. There was some discussion
about the new autoconf and libtool. Dunno where it is right now. APR should
be required to be able to work with the new tools, tho. Patches there should
be fine, as long as both 1.3.x and 1.4 work for it.
Note that we (effectively) ship a copy of libtool with SVN. End users don't
need libtool installed. Thus, the libtool 1.4 requirement would apply only
to developers. (read: totally fine)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: libtool 1.4 problem
Posted by Joe Orton <jo...@btconnect.com>.
On Mon, Jul 02, 2001 at 07:21:01PM +0100, Tim Waugh wrote:
> On Mon, Jul 02, 2001 at 12:09:05PM -0500, Ben Collins-Sussman wrote:
>
> > So your patch looks like it's basically removing ".libs" wherever it
> > can from build system paths. Obviously, Greg Stein didn't put those
> > in there extraneously -- so I assume your patch will *break* the build
> > for libtool 1.3.5, right?
>
> I'm pretty sure this isn't the case. I have seen similar problems
> with another package (openjade): the .libs is superfluous. It's a
> libtool-internal thing, and shouldn't need to be explicitly
> referenced.
IIRC the .libs thing was to get inter-library dependencies working:
something that libtool 1.3 doesn't support but 1.4 does (I think in
theory the build can be simplified further by requiring 1.4, not that I
am advocating that position since I'm hand-waving)
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: libtool 1.4 problem
Posted by Tim Waugh <tw...@redhat.com>.
On Mon, Jul 02, 2001 at 12:09:05PM -0500, Ben Collins-Sussman wrote:
> So your patch looks like it's basically removing ".libs" wherever it
> can from build system paths. Obviously, Greg Stein didn't put those
> in there extraneously -- so I assume your patch will *break* the build
> for libtool 1.3.5, right?
I'm pretty sure this isn't the case. I have seen similar problems
with another package (openjade): the .libs is superfluous. It's a
libtool-internal thing, and shouldn't need to be explicitly
referenced.
Tim.
*/
Re: libtool 1.4 problem
Posted by Jon Trowbridge <tr...@ximian.com>.
On 02 Jul 2001 12:09:05 -0500, Ben Collins-Sussman wrote:
> Jon Trowbridge <tr...@ximian.com> writes:
>
> So your patch looks like it's basically removing ".libs" wherever it
> can from build system paths. Obviously, Greg Stein didn't put those
> in there extraneously -- so I assume your patch will *break* the build
> for libtool 1.3.5, right?
>
> Is this just a fundamental incompatibility between libtool versions?
Maybe. There was a comment somewhere that said it was working around
"libtool 1.3.5 bugs". And this patch will break the libtool 1.3.5
build.
Explicit references to .libs should never be necessary. So either there
were in fact libtool 1.3.5 bugs, or it was a problem with the build
system/libtool 1.3.5 interaction. In any case, these work-around hacks
are definitely part of the problem.
One possible fix for the install _might_ be to create a hacked,
subversion-specific version of apr/build/install.sh that moves back up
to the top-level directory before trying to install anything. I'll
experiment with that tonight.
In any case, I have a feeling that you guys are going to have to declare
libtool 1.4 the one-true-libtool for building subversion.
-JT
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: libtool 1.4 problem
Posted by Ben Collins-Sussman <su...@collab.net>.
Jon Trowbridge <tr...@ximian.com> writes:
> This isn't the main problem. I'm attaching a patch containing my
> efforts to get things to work w/ libtool 1.4 (which GNOME requires now,
> among other things), which works around this.
>
> The problem is that, during installs, when libtool needs to relink
> libraries, it descends into the subdirectories and doesn't come back out
> before trying to finish the install. Thus all of the relative pathnames
> generated are wrong, and the install fails.
So your patch looks like it's basically removing ".libs" wherever it
can from build system paths. Obviously, Greg Stein didn't put those
in there extraneously -- so I assume your patch will *break* the build
for libtool 1.3.5, right?
Is this just a fundamental incompatibility between libtool versions?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: libtool 1.4 problem
Posted by Jon Trowbridge <tr...@ximian.com>.
On 02 Jul 2001 11:19:09 -0500, Ben Collins-Sussman wrote:
>
> A friend of ours has discovered a compatibility problem between
> the latest libtool (1.4) and our build system.
>
> I was able to reproduce the problem myself. Here's what I did:
>
> * virgin RedHat 7.0 system
> * built & installed db3.2.9 and libtool 1.4
> * checked out subversion, apr, neon.
> * ./autogen && ./configure --enable-maintainer-mode --disable-shared
>
> When I run `make`, I get errors linking the svn binary:
> (snip)
> Our friend theorizes that the new libtool is somehow confused by our
> non-recursive make system. I don't know enough to diagnose. Anyone
> have a definitive analysis of the problem?
I'm the "friend".
This isn't the main problem. I'm attaching a patch containing my
efforts to get things to work w/ libtool 1.4 (which GNOME requires now,
among other things), which works around this.
The problem is that, during installs, when libtool needs to relink
libraries, it descends into the subdirectories and doesn't come back out
before trying to finish the install. Thus all of the relative pathnames
generated are wrong, and the install fails.
(This recursive descent isn't a problem normally, because the whole
autofoo tool-chain does recusive makes.)
One solution might be to make all install-related pathnames in the
generated makefile absolute paths. Which is kind of gross, but might be
necessary if you want to be able to assume that you are always operating
from the top-level directory.
-JT
Re: libtool 1.4 problem
Posted by Ben Collins-Sussman <su...@collab.net>.
josh lucas <jo...@stonecottage.com> writes:
> > Our friend theorizes that the new libtool is somehow confused by our
> > non-recursive make system. I don't know enough to diagnose. Anyone
> > have a definitive analysis of the problem?
>
> fwiw, I was getting these symptoms (not with subversion but with
> compiling evolution and nautilus) until I upped to autoconf 2.50 as
> well... Seems that if libtool and autoconf are out of this sync, bad
> things happen...
I just upgraded the system to autoconf 2.50, repeated the whole
process, and the errors have *not* gone away. They're exactly the
same. :-(
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: libtool 1.4 problem
Posted by josh lucas <jo...@stonecottage.com>.
Ben Collins-Sussman wrote:
>
> A friend of ours has discovered a compatibility problem between
> the latest libtool (1.4) and our build system.
>
> I was able to reproduce the problem myself. Here's what I did:
>
> * virgin RedHat 7.0 system
> * built & installed db3.2.9 and libtool 1.4
> * checked out subversion, apr, neon.
> * ./autogen && ./configure --enable-maintainer-mode --disable-shared
>
> When I run `make`, I get errors linking the svn binary:
>
> =======================================================================
> cd subversion/clients/cmdline && /bin/sh /home/sussman/projects/subversion/libtool --silent --mode=link gcc -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -g -Wall -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -pthread -Wpointer-arith -Wwrite-strings -Wshadow -DSVN_DEBUG -DAP_DEBUG -I./subversion/include -I. -I./apr/include -I./neon/src -I./expat-lite -I/usr/local/BerkeleyDB.3.2/include -rpath /usr/local/lib -o svn add-cmd.o checkout-cmd.o commit-cmd.o delete-cmd.o diff-cmd.o diff.o feedback.o help-cmd.o import-cmd.o main.o propget-cmd.o proplist-cmd.o props.o propset-cmd.o status-cmd.o status.o trace-commit.o trace-update.o update-cmd.o util.o ../../../subversion/libsvn_client/libsvn_client.la ../../../subversion/libsvn_wc/libsvn_wc.la ../../../subversion/libsvn_ra/libsvn_ra.la ../../../subversion/libsvn_delta/libsvn_delta.la ../../../subversion/libsvn_subr/libsvn_subr.la /home/sussman/projects/subversion/apr/libapr.la /home/!
su!
> ssman/projects/subversion/apr/shmem/unix/mm/libmm.la ../../../expat-lite/libexpat.la -lm -lcrypt -lnsl -ldl
> gcc: /home/sussman/projects/subversion/subversion/libsvn_ra_dav/.libs/.libs/libsvn_ra_dav.a: No such file or directory
> gcc: /home/sussman/projects/subversion/neon/src/.libs/.libs/libneon.a: No such file or directory
> gcc: /home/sussman/projects/subversion/subversion/libsvn_ra_local/.libs/.libs/libsvn_ra_local.a: No such file or directory
> gcc: /home/sussman/projects/subversion/subversion/libsvn_delta/.libs/.libs/libsvn_delta.a: No such file or directory
> gcc: /home/sussman/projects/subversion/subversion/libsvn_subr/.libs/.libs/libsvn_subr.a: No such file or directory
> gcc: /home/sussman/projects/subversion/subversion/libsvn_repos/.libs/.libs/libsvn_repos.a: No such file or directory
> gcc: /home/sussman/projects/subversion/subversion/libsvn_fs/.libs/.libs/libsvn_fs.a: No such file or directory
> make: *** [subversion/clients/cmdline/svn] Error 1
> =======================================================================
>
> Our friend theorizes that the new libtool is somehow confused by our
> non-recursive make system. I don't know enough to diagnose. Anyone
> have a definitive analysis of the problem?
fwiw, I was getting these symptoms (not with subversion but with
compiling evolution and nautilus) until I upped to autoconf 2.50 as
well... Seems that if libtool and autoconf are out of this sync, bad
things happen...
josh
josh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org