There is subtle difference between our CTNG_PYTHON and the AX_PYTHON on
which it is based. The latter uses AC_CHECK_PROGS() which sets
PYTHON_BIN to the name of the executable. We use AC_PATH_PROGS() which
sets PYTHON_BIN to the full path of the executable.
Because the name of the executable is the same as the library AX_PYTHON
uses this when looking for the library with AC_CHECK_LIB() which magics
itself into a linker flag like `-lpython3.11` but our version ends up
with a nonsensical `-l/usr/bin/python3.11` so the check fails and we
keep iterating repeating the same wrong check for every tested python
version.
We can't just switch to using AC_CHECK_PROGS() because we do want to use
the variable set by AC_PATH_PROGS() to set the full path in paths.sh.
Ultimately we could probably switch to using the upstream AX_PYTHON
macro (https://www.gnu.org/software/autoconf-archive/ax_python.html) and
figure out a better way of getting the full path of the exectuable but
for now add an extra AC_CHECK_PROGS() to set a different variable and
use that for AC_CHECK_LIB().
Signed-off-by: Chris Packham <judge.packham@gmail.com>
We use the information from various configure time checks to populate
paths.sh. The paths used are all absolute except for the python binary.
In the switch to a more comprehensive check for python by commit
fa05153e ("Make checking for python more predictable.") we ended up
using AC_CHECK_PROGS which checks for the program on the path and sets
the variable to the name of the program. This makes python inconsistent
with the other programs and seems to cause problems for MSYS2. Use
AC_PATH_PROGS instead which does the same check but sets the variable to
the absolute name of the program
Fixes#2047
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reverts the changes introduced to `m4/ax_with_curses_extra.m4`
in 59b664806c55dc1e5878448be2536fe110944f62,
which seem to make `cofigure` look only for `ncursesw/panel.h`
and not consider `panel.h` as a candidate,
thus causing `./configure` to fail with
"error: panel library not found" on systems
(such as Arch Linux) where ncurses headers
are not put under the `ncursesw/` directory.
Signed-off-by: Pavel Grigorenko <grigorenkopv@ya.ru>
... which fixes <panel.h> detection on Alpine Linux (which has ncursesw
but installs it into plain /usr/include).
Signed-off-by: Alexey Neyman <stilor@att.net>
... unless one retrofits it with a decent compiler instead of stock
GCC 4.4.
While here, sync up the ax_*.m4 with autoconf-archive.
Signed-off-by: Alexey Neyman <stilor@att.net>
- Force building make as a companion tool if host make is older than
4.0 (CentOS 7 currently has 3.82)
- Disable 2.29 as a choice if host python is older than 3.4
(CentOS 7 has 2.6 unless python from EPEL is installed)
- Python2 emits its version information to STDERR. Ugh.
While there, also use the detected host Python for GDB configuration.
Signed-off-by: Alexey Neyman <stilor@att.net>
... otherwise it fails for autoconf/automake; for some reason, newer
Ubuntu 18.10 adds extra quoting around '${SHELL}' in
$ac_cv_path_AUTOCONF.
Signed-off-by: Alexey Neyman <stilor@att.net>