#135 closed enhancement (fixed)
[patch] Upgrade to requiring autoconf 2.60 or newer
Reported by: | Tom Mortimer | Owned by: | Olly Betts |
---|---|---|---|
Priority: | lowest | Milestone: | 1.1.0 |
Component: | Build system | Version: | SVN trunk |
Severity: | minor | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Operating System: | All |
Description (last modified by )
xapian $ ./bootstrap Bootstrapping `xapian-core' You should update your `aclocal.m4' by running aclocal. configure.ac:386: error: possibly undefined macro: AC_TYPE_SSIZE_T
If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1 Bootstrap failed --
gcc 4.0.1, GNU autoconf 2.59, GNU automake 1.9.5, GNU libtool 1.5.22
(going to try with later autoconf at RB's suggestion. More helpful error message please?)
Attachments (1)
Change History (10)
comment:1 by , 18 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:2 by , 18 years ago
We could just revert the change to use AC_TYPE_SSIZE_T - it's hardly a rocket science test. I just changed to using it because I noticed it was there when adding a check for AC_TYPE_MODE_T (which doesn't seem to be so new).
2.59c is a beta release, so really we're now requiring 2.60, which would allow some compatibility cruft to be removed and also mean that people are developing against a version closer to that we use for snapshots and releases (2.61 currently).
Ubuntu edgy has 2.60; the new Debian stable has 2.61. Debian oldstable had 2.59a, but I find it hard to believe anyone doing major development work would be able to use Debian stable for long after release without backports or hand built packages, and besdies they'll be looking to upgrade soon anyway. I don't know about other distros or package based platforms though.
Casual users can also use the SVN snapshots anyway. I think I've convinced myself at least! Would autoconf 2.60 be a problem for you, Tom?
comment:3 by , 18 years ago
Answering for Tom - he has 2.61 installed on his machine now, so no problem for him.
Ubuntu Dapper is the only platform I can think of which might have 2.59 on it, but I've not got any machines running that around any more. Hmm, http://packages.ubuntulinux.org/dapper/source/autoconf implies that it's has 2.59a-7. I think it's okay to require developers on that to use newer tools if they want to work on xapian, though.
The real important thing is that we give a useful error message, which we do now.
comment:4 by , 18 years ago
op_sys: | MacOS X → All |
---|---|
Priority: | normal → lowest |
rep_platform: | Macintosh → All |
Resolution: | fixed |
Severity: | normal → enhancement |
Status: | closed → reopened |
Summary: | bootstrap fails on Intel Mac → [patch] Upgrade to requiring autoconf 2.60 or newer |
I've had to revert to requiring autoconf 2.59 for the benefit of older RPM building Linux distributions - the .spec file runs autoreconf to pick up local bugfixes for a libtool rpath bug on 64 bit hosts, which was failing because some still have autoconf 2.59.
I'll attach the patch which did the reverting (so apply with patch -R) for when we eventually upgrade to requiring 2.60 or newer again.
Retitling etc as appropriate.
by , 18 years ago
Attachment: | xapian-back-to-autoconf-2.59.patch added |
---|
Patch which reverted to requring autoconf 2.59
comment:5 by , 17 years ago
Blocking: | 160 added |
---|---|
Operating System: | → All |
We should consider the required versions of autoconf, automake, and libtool for 1.1.0.
comment:6 by , 17 years ago
libtool 2.2 is now out, and a patchlevel release should appear shortly. We should try it out for 1.1.0, if only to shake out any bugs which matter to us.
comment:8 by , 17 years ago
Description: | modified (diff) |
---|---|
Milestone: | → 1.1 |
comment:9 by , 17 years ago
Blocking: | 160 removed |
---|
comment:10 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Fixed in trunk rev [11185].
Fixed with change to xapian-core/configure.ac.