<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi strk,<br><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 27, 2018 at 11:23 AM Sandro Santilli <<a href="mailto:strk@kbt.io">strk@kbt.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> if the autoconf dependency is a hard dependency for 2.64, or if it would be<br>
> reasonably okay to build with autoconf 2.63.<br>
<br>
In the top-level <a href="http://configure.ac" rel="noreferrer" target="_blank">configure.ac</a> we are requesting 2.52 as a dependency,<br>
but I see macros/* are raising that:<br>
<br>
  $ grep PREREQ <a href="http://configure.ac" rel="noreferrer" target="_blank">configure.ac</a> macros/*<br>
  configure.ac:AC_PREREQ([2.52])<br>
  macros/ax_check_compile_flag.m4:[AC_PREREQ(2.64)dnl for _AC_LANG_PREFIX and AS_VAR_IF<br>
  macros/libtool.m4:# LT_PREREQ(VERSION)<br>
  macros/libtool.m4:m4_defun([LT_PREREQ],<br>
  macros/libtool.m4:[AC_PREREQ([2.62])dnl We use AC_PATH_PROGS_FEATURE_CHECK<br>
<br>
>From the comment in ax_check_compile_flag.m4 it would sound like<br>
something would break with anyting < 2.64 (not recognizing support<br>
for some compiler flags?). It is likely that you can still build<br>
without those compiler flags passed, but you may not obtain the same<br>
results as we're basing our tests on.<br></blockquote><div><br></div><div>Understood.  I guess I'm trying to figure out if 2.64 was just picked because it was an important release, or if it was something specifically relevant to the toolchain for geos.  I can see that the the origin of the file for the geos code was updated from 2.59 to 2.64 with this patch in 2015:</div><div><a href="http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=commitdiff;h=1a869696e4129279f7b99c3f9052717354b79a86">http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=commitdiff;h=1a869696e4129279f7b99c3f9052717354b79a86</a><br></div><div><br></div><div>I found a page that said that 2.64 was important because the behavior of some functionality changed with regards to compilation handling and headers:</div><div><a href="https://autotools.io/forwardporting/autoconf.html">https://autotools.io/forwardporting/autoconf.html</a><br></div><div>However, I'm not sure if that's relevant to geos 3.7, or if it's just a thing that was taken because it was upstream.</div><div><br></div><div>I'm sorry if this sounds like an irrelevant question but if 2.64 is a hard requirement, the consequence is that CentOS 6 becomes essentially "not compilable out of the box", and this has a cascading impact on PostGIS 2.5 which is dependent on geos 3.7.  CentOS 6 is still in support until 2020, so it would be a shame to require a custom-built toolchain not available via RPM if it wasn't truly necessary.  I figured it would be worth the question.</div><div><br></div><div>Maybe a better question would be-- is there a way I can test my compilation of geos 3.7.0 on CentOS 6 with autoconf 2.63 to validate that it seems to be working correctly?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In any case it looks like our top-level requirement is too low,<br>
for libtool to work ... Do you feel like sending a patch to clean<br>
things up ?<br></blockquote><div><br></div><div>I'd be happy to try to patch whatever's needed.  Are you just asking me to bump up <a href="http://configure.ac">configure.ac</a> from 2.52 to 2.64 and libtool.m4 from 2.62 to 2.64?  Or, do I need to do a deeper dive into libtool?</div><div><br></div><div>Thanks!</div><div>  -John Harvey </div></div></div></div></div></div>