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 <ju...@erenkrantz.com> on 2004/02/23 19:04:57 UTC
Bumping libtool version was Re: Problem compiling 1.0.0beta1 on
Solaris 9
--On Monday, February 23, 2004 7:31 PM +0100 Michael Legart
<mi...@legart.dk> wrote:
> Philip Martin wrote:
>>
>> So it would appear that either the autoconf or libtool used in the
>> tarball don't properly support Solaris. Which versions do you have
>> installed?
>
> I'm using autoconf (GNU Autoconf) 2.57 and ltmain.sh (GNU libtool) 1.5
> (1.1220 2003/04/05 19:32:58)
FWIW, libtool 1.4.3 works for me here on Solaris 9. However, I'm using forte.
It's *very* possible that libtool 1.4.3 has some problems with the GCC 3.x
series on Solaris. So, yeah, perhaps we should bump up our release
requirement for libtool to 1.5+ (1.5.2 is latest?). (I don't *think* autoconf
would be involved.)
Also, Greg Hudson on IRC said that DESTDIR isn't supported in libtool 1.4.3,
so that's probably a reason to upgrade as well. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bumping libtool version was Re: Problem compiling 1.0.0beta1
on Solaris 9
Posted by Michael Legart <mi...@legart.dk>.
Philip Martin wrote:
> Michael, you said that the 0.37 tarball worked. If you still have
> that tarball (I can't find it) unpack it, run ./configure and then run
> ./configure --version and ./libtool --version to see what versions
> it used.
Just retried it and yes, it works.
$ ./configure --version
subversion configure 0.37.0
generated by GNU Autoconf 2.57
$ ./libtool --version
ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54)
using http://subversion.tigris.org/tarballs/subversion-0.37.0.tar.gz
With 1.0.0 i get:
$ ./configure --version
subversion configure 1.0.0
generated by GNU Autoconf 2.53
$ ./libtool --version
ltmain.sh (GNU libtool) 1.4.3 (1.922.2.111 2002/10/23 02:54:36)
So it looks like it could be because of the autoconf version?
/Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bumping libtool version was Re: Problem compiling 1.0.0beta1 on Solaris 9
Posted by kf...@collab.net.
Sander Striker <st...@apache.org> writes:
> It seems like overkill to me. The only thing that is troublesome is
> libtool. In the buildcheck --release code we can do the check for
> the correct libtool version and then ask a question:
>
> """
> libtool 1.4.3 detected in <path>. If this is the libtool that comes
> with your system it is possible that it has vendor patches applied,
> which is known to cause problems. You can find a pristine version
> of libtool 1.4.3 here:
>
> <url_to_libtool>
>
> Are you sure that a pristine libtool is being used? [y/n] .
> """
>
> A simple solution that simply reminds the RM what is up. No need
> for anything more difficult IMO.
That's probably enough. Indeed, I had assumed the tools were
*already* doing this for me -- since the libtool check failed on one
platform during buildcheck, I assumed that when it didn't fail
somewhere else, everything must be all right. Of course, everything
was all right for just a build, but not for a dist. Which means
dist.sh should do a stricter check than buildcheck does.
Since I have this problem on my home machine, I'll take a look at
making such a check.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bumping libtool version was Re: Problem compiling 1.0.0beta1
on Solaris 9
Posted by Sander Striker <st...@apache.org>.
On Tue, 2004-02-24 at 03:15, Ben Reser wrote:
> On Mon, Feb 23, 2004 at 02:56:51PM -0600, kfogel@collab.net wrote:
> > That's why I want to make a build box that doesn't get used for normal
> > development (which might cause tool impurities). I'm thinking
> > newton.ch.collab.net could be it.
>
> Why not just setup a minimal chroot on a machine with only the minimal
> tools compiled for x86 installed in it. We could even pass this
> directory between developers. As long as we use x86 machines and
> binaries and the developer has root access to a Linux box it should work
> fine. Baring a kernel issue that impacts our release packaging (which I
> highly doubt) this would be an extremely portable way of dealing with
> such issues.
It seems like overkill to me. The only thing that is troublesome is
libtool. In the buildcheck --release code we can do the check for
the correct libtool version and then ask a question:
"""
libtool 1.4.3 detected in <path>. If this is the libtool that comes
with your system it is possible that it has vendor patches applied,
which is known to cause problems. You can find a pristine version
of libtool 1.4.3 here:
<url_to_libtool>
Are you sure that a pristine libtool is being used? [y/n] .
"""
A simple solution that simply reminds the RM what is up. No need
for anything more difficult IMO.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bumping libtool version was Re: Problem compiling 1.0.0beta1 on Solaris 9
Posted by Ben Reser <be...@reser.org>.
On Mon, Feb 23, 2004 at 02:56:51PM -0600, kfogel@collab.net wrote:
> That's why I want to make a build box that doesn't get used for normal
> development (which might cause tool impurities). I'm thinking
> newton.ch.collab.net could be it.
Why not just setup a minimal chroot on a machine with only the minimal
tools compiled for x86 installed in it. We could even pass this
directory between developers. As long as we use x86 machines and
binaries and the developer has root access to a Linux box it should work
fine. Baring a kernel issue that impacts our release packaging (which I
highly doubt) this would be an extremely portable way of dealing with
such issues.
I'd be happy to build such a chroot or help someone else do it.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bumping libtool version was Re: Problem compiling 1.0.0beta1 on Solaris 9
Posted by kf...@collab.net.
Sander Striker <st...@apache.org> writes:
> This is the same issue that happens again and again. I've been
> bitten by it too. The trick is that a RM needs to have a _prisitine_
> libtool 1.4.3 in his path. I installed it in my homedir and add
> it as the first thing in my PATH when doing releases.
That's why I want to make a build box that doesn't get used for normal
development (which might cause tool impurities). I'm thinking
newton.ch.collab.net could be it.
> Karl, I remember that we hunted for libtool 1.4.3 past november when
> doing a point release ;) :). Did you forget? Not really that weird
> in the middle of the night, while being /.'ed ;).
I did forgot, you bet! :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bumping libtool version was Re: Problem compiling 1.0.0beta1
on Solaris 9
Posted by Sander Striker <st...@apache.org>.
On Mon, 2004-02-23 at 20:36, kfogel@collab.net wrote:
> Philip Martin <ph...@codematters.co.uk> writes:
> > Michael, you said that the 0.37 tarball worked. If you still have
> > that tarball (I can't find it) unpack it, run ./configure and then run
> > ./configure --version and ./libtool --version to see what versions
> > it used.
> >
> > I seem to remember we had a problem in the past when the tarball was
> > made with Debian's patched libtool rather than a pristine upstream
> > one. Karl, can you say what versions were used? They identify
> > themselves as
> > GNU Autoconf 2.53
> > ltmain.sh (GNU libtool) 1.4.3 (1.922.2.111 2002/10/23 02:54:36)
>
> That seems right.
>
> It was my home machine (which I don't have access too from here ATM).
> But I can tell you that I first tried to build the tarball on my work
> machine, and buildcheck complained:
>
> You need libtool version 1.4.3 or newer installed
>
> So I moved the process to the home machine, and buildcheck didn't
> complain there. But, my home machine *is* a Debian 'testing' box.
This is the same issue that happens again and again. I've been
bitten by it too. The trick is that a RM needs to have a _prisitine_
libtool 1.4.3 in his path. I installed it in my homedir and add
it as the first thing in my PATH when doing releases.
Karl, I remember that we hunted for libtool 1.4.3 past november when
doing a point release ;) :). Did you forget? Not really that weird
in the middle of the night, while being /.'ed ;).
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bumping libtool version was Re: Problem compiling 1.0.0beta1 on Solaris 9
Posted by Colin Watson <cj...@flatline.org.uk>.
On Mon, Feb 23, 2004 at 08:49:21PM +0000, Philip Martin wrote:
> kfogel@collab.net writes:
> > Philip Martin <ph...@codematters.co.uk> writes:
> >> I seem to remember we had a problem in the past when the tarball was
> >> made with Debian's patched libtool rather than a pristine upstream
> >> one.
>
> > my home machine *is* a Debian 'testing' box.
>
> I think that's the problem, I don't suppose Debian's patches get
> tested on Solaris, or any other "foreign" system.
The Debian libtool maintainer is also one of the upstream libtool
developers, and actively syncing patches there; so it's probably a good
idea to make sure that you can cope with the 1.6-track libtool.
--
Colin Watson [cjwatson@flatline.org.uk]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bumping libtool version was Re: Problem compiling 1.0.0beta1 on
Solaris 9
Posted by Philip Martin <ph...@codematters.co.uk>.
kfogel@collab.net writes:
> Philip Martin <ph...@codematters.co.uk> writes:
>>
>> I seem to remember we had a problem in the past when the tarball was
>> made with Debian's patched libtool rather than a pristine upstream
>> one.
> my home machine *is* a Debian 'testing' box.
I think that's the problem, I don't suppose Debian's patches get
tested on Solaris, or any other "foreign" system. (Testing is up to
1.5.2 btw.)
> I'm thinking we should establish a build box & maintain the right
> tools there, and not have to worry about this again.
A local installation of the pristine tools and an appropriate path
should be OK.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bumping libtool version was Re: Problem compiling 1.0.0beta1 on Solaris 9
Posted by kf...@collab.net.
Philip Martin <ph...@codematters.co.uk> writes:
> Michael, you said that the 0.37 tarball worked. If you still have
> that tarball (I can't find it) unpack it, run ./configure and then run
> ./configure --version and ./libtool --version to see what versions
> it used.
>
> I seem to remember we had a problem in the past when the tarball was
> made with Debian's patched libtool rather than a pristine upstream
> one. Karl, can you say what versions were used? They identify
> themselves as
> GNU Autoconf 2.53
> ltmain.sh (GNU libtool) 1.4.3 (1.922.2.111 2002/10/23 02:54:36)
That seems right.
It was my home machine (which I don't have access too from here ATM).
But I can tell you that I first tried to build the tarball on my work
machine, and buildcheck complained:
You need libtool version 1.4.3 or newer installed
So I moved the process to the home machine, and buildcheck didn't
complain there. But, my home machine *is* a Debian 'testing' box.
I'm thinking we should establish a build box & maintain the right
tools there, and not have to worry about this again.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bumping libtool version was Re: Problem compiling 1.0.0beta1 on
Solaris 9
Posted by Philip Martin <ph...@codematters.co.uk>.
Justin Erenkrantz <ju...@erenkrantz.com> writes:
> --On Monday, February 23, 2004 7:31 PM +0100 Michael Legart
> <mi...@legart.dk> wrote:
>
>> Philip Martin wrote:
>>>
>>> So it would appear that either the autoconf or libtool used in the
>>> tarball don't properly support Solaris. Which versions do you have
>>> installed?
>>
>> I'm using autoconf (GNU Autoconf) 2.57 and ltmain.sh (GNU libtool) 1.5
>> (1.1220 2003/04/05 19:32:58)
>
> FWIW, libtool 1.4.3 works for me here on Solaris 9. However, I'm
> using forte. It's *very* possible that libtool 1.4.3 has some problems
> with the GCC 3.x series on Solaris. So, yeah, perhaps we should bump
> up our release requirement for libtool to 1.5+ (1.5.2 is latest?). (I
> don't *think* autoconf would be involved.)
>
> Also, Greg Hudson on IRC said that DESTDIR isn't supported in libtool
> 1.4.3, so that's probably a reason to upgrade as well. -- justin
Michael, you said that the 0.37 tarball worked. If you still have
that tarball (I can't find it) unpack it, run ./configure and then run
./configure --version and ./libtool --version to see what versions
it used.
I seem to remember we had a problem in the past when the tarball was
made with Debian's patched libtool rather than a pristine upstream
one. Karl, can you say what versions were used? They identify
themselves as
GNU Autoconf 2.53
ltmain.sh (GNU libtool) 1.4.3 (1.922.2.111 2002/10/23 02:54:36)
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bumping libtool version was Re: Problem compiling 1.0.0beta1
on Solaris 9
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2004-02-23 at 15:45, Joe Orton wrote:
> Of these problems I'd worry least about DESTDIR installs failing: people
> doing DESTDIR installs are probably packagers and can just run
> autogen.sh in their package builds using known-good version of libtool.
I can provide a patch against libtool 1.4.3 to fix just the DESTDIR
problem, if that would help. People have certainly reported being
bitten by it a couple of times during the course of svn's development.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bumping libtool version was Re: Problem compiling 1.0.0beta1 on Solaris 9
Posted by Joe Orton <jo...@manyfish.co.uk>.
On Mon, Feb 23, 2004 at 11:04:57AM -0800, Justin Erenkrantz wrote:
> --On Monday, February 23, 2004 7:31 PM +0100 Michael Legart
> <mi...@legart.dk> wrote:
>
> >Philip Martin wrote:
> >>
> >>So it would appear that either the autoconf or libtool used in the
> >>tarball don't properly support Solaris. Which versions do you have
> >>installed?
> >
> >I'm using autoconf (GNU Autoconf) 2.57 and ltmain.sh (GNU libtool) 1.5
> >(1.1220 2003/04/05 19:32:58)
>
> FWIW, libtool 1.4.3 works for me here on Solaris 9. However, I'm using
> forte. It's *very* possible that libtool 1.4.3 has some problems with the
> GCC 3.x series on Solaris. So, yeah, perhaps we should bump up our release
> requirement for libtool to 1.5+ (1.5.2 is latest?). (I don't *think*
> autoconf would be involved.)
>
> Also, Greg Hudson on IRC said that DESTDIR isn't supported in libtool
> 1.4.3, so that's probably a reason to upgrade as well. -- justin
Yeah, the Debian-patched libtool-1.4.3 used to package 1.0.0 has both a
patch to fix DESTDIR installs, and a patch to ignore -pthread on link
lines.
Use of libtool 1.5/1.5.2 is not advisable since the configure script
would then fail on systems without a C++ compiler.
Of these problems I'd worry least about DESTDIR installs failing: people
doing DESTDIR installs are probably packagers and can just run
autogen.sh in their package builds using known-good version of libtool.
So libtool 1.4.3 probably remains the version of choice.
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org