Hello,
In that change I bumped the number from 2.61 to 2.67. The original 2.61
was put there by Fredrik very early in the build-infra conversion and I
don't know where that came from. The main reason for us to pick just one
version was because we wanted to avoid large differences in the
committed generated file. Since we are no longer committing the file, I
don't see a good reason to enforce a particular version, but we also
should not change this number until someone has verified that a
particular version works reasonably well.
It should also be noted that installing autoconf from src is trivially
simple. The build has very few prerequisites and takes seconds to
complete. I've never failed on any of the platforms I've tried it on
over the years.
/Erik
On 2018-02-05 12:14, Magnus Ihse Bursie wrote:
On 2018-02-05 21:05, Magnus Ihse Bursie wrote:
Let's move this discussion to build-dev instead of jdk-dev.
On 2018-02-05 17:30, Thomas Stüfe wrote:
Hi Magnus,
On Mon, Feb 5, 2018 at 9:21 AM, Magnus Ihse Bursie
<magnus.ihse.bur...@oracle.com
<mailto:magnus.ihse.bur...@oracle.com>> wrote:
<snip> With the new solution, the exact version of autoconf does
not matter. <snip>
It seems to matter. I now get:
Using autoconf at /usr/bin/autoconf [autoconf (GNU Autoconf) 2.63]
stdin:33: error: Autoconf version 2.69 or higher is required
stdin:33: the top level
autom4te: /usr/bin/m4 failed with exit status: 63
Do we actually need this strict check for the autoconf version? Is
there a way to disable the check and retry with my old version?
The check is enforced by
AC_PREREQ([2.69])
in the top of make/autoconf/configure.ac.
You could try removing it and see what happens. In the "best" case
you'll get an error message when autoconf tries to generate the file,
then we know for certain that it does not work. :-) Otherwise, you'll
have to test the generated configure file more thoroughly to ensure
that it really works.
I'm quite certain that older versions (and believe me, everything
prior to 2.69 is *ancient*) did not work at all, and that was the
reason we added that requirement.
Some code archeology gave me this:
https://bugs.openjdk.java.net/browse/JDK-8023957
It seems that we at least supported 2.67 at the time, but we
executable was not commonly (?) named "autoconf" so we couldn't
autodetect it. Still can't say about 2.63 though.
/Magnus
I would dislike for this to be a frequent error now - unfortunately,
we have some build environments where getting the latest GNU tools
is more work than just running an installer.
Thanks, Thomas
The build documentation has been updated to reflect this change.
/Magnus
