In trying to get sqlite3 built for 64-bit Cygwin, I've run into a wall:
during the cygport compile step, it runs
autoreconf --force -i --verbose
This overwrites the config.guess shipped with SQLite with the one from
automake 1.9. (I know this for a fact based on file sizes.) That old
version doesn't understand Cygwin 64, so it gives a verbose error that
amounts to "upgrade, dude." If autoreconf were to grab the config.guess
from automake 1.13 or the one shipped with Cygport itself, all would be
well.
I'm guessing this happens due to this line in SQLite's configure script:
am__api_version="1.9"
I can't run autoconf to re-generate this, since the configure.ac file
has a bunch of old constructs that autoconf 2.69 barfs on.
I don't want to suppress the autoreconf step, since the SQLite tarball
*also* includes an outdated config.guess script. So, autoreconf *does*
need to be run. It just needs to be made to DTRT.
My subject line refers to the fact that even if I copy a good
config.guess file in by hand between the prep and compile steps,
autoreconf overwrites it anyway, probably because of the --force flag.
Ultimately, upstream should upgrade their autotools and fix their .in
and .ac files, but seeing as how they just applied a trivial patch I
provided 3 years ago, I'm not going to hold my breath waiting.
Any suggestions on how to fix this without involving upstream, and
without wholesale replacement of the autotools input files shipped with
the SQLite tarball?
My guess is that it would be best if I could slip a custom step in
between the 'autoreconf' step and the 'make' step, hand-copying in an
up-to-date version of config.guess from somewhere. Does cygport have
such a hook?
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
