Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Python 3.11 not allowed #456

Closed
0-wiz-0 opened this issue Aug 24, 2023 · 6 comments
Closed

Python 3.11 not allowed #456

0-wiz-0 opened this issue Aug 24, 2023 · 6 comments

Comments

@0-wiz-0
Copy link

0-wiz-0 commented Aug 24, 2023

When trying to build with Python 3.11 installed, I see:

checking whether /usr/pkg/bin/python3.11 version is >= 3.7... no
configure: error: Python interpreter is too old

Please fix this, 3.11 is newer than 3.7.

@trofi
Copy link
Collaborator

trofi commented Aug 24, 2023

Hi! This is absolutely expected to work. The build works for me on python-3.11, automake-1.16.5 and autoconf-2.71 (or autoconf-2.69). Thus we need to figure out what is special about your environment.

re2c does very simple standard python version check at: https://github.com/skvadrik/re2c/blob/0b6d0b510ec4e1a551aca08b9de5c02d63a11ce7/configure.ac#L16C14-L16C14

AM_PATH_PYTHON([3.7])

It's an automake macro: https://www.gnu.org/software/automake/manual/html_node/Python.html

A few questions for you:

  1. which automake and autoconf versions you are using
  2. can you attach failed config.log as well? Chances are it will tell us what is wrong with version check.
  3. where did you pick re2c version? is it a git checkout or ` release tarball? release tarball might have a better chance of working in old environments as it does not rely on installed autoconf versions.

@0-wiz-0
Copy link
Author

0-wiz-0 commented Aug 24, 2023

I'm using the 3.1 tarball.

I've just tried reproducing it in a minimal environment and see:

checking for a Python interpreter with version >= 3.7... none
configure: error: no suitable Python interpreter found

It works there if I make a symlink from python3.11 to python3 - but the configure script only knows python versions up to 3.9:

for am_cv_pathless_PYTHON in python python2 python3  python3.9 python3.8 python3.7 python3.6 python3.5 python3.4 python3.3  python3.2 python3.1 python3.0  python2.7 python2.6 python2.5 python2.4 python2.3 python2.2 python2.1  python2.0 none; do

IIRC this is fixed in automake upstream but no release has been made including this.

@trofi
Copy link
Collaborator

trofi commented Aug 24, 2023

Aha, you probably mean the https://git.savannah.gnu.org/cgit/automake.git/commit/?id=930a9a73f4bb776ec334eff4cf6e182802841daa. Looks like it's the only change in m4/python.m4.

AFAIU that change only fixes default python version detection that should be workaroundable with PYTHON=python3.11 ./configure or the equivalent.

We should be able to regenerate re2c tarball with patches automake (even better would be to have an automake upstream release).

What I'm confused about is why you get the initial failure:

checking whether /usr/pkg/bin/python3.11 version is >= 3.7... no

If I provide only environment that has /usr/bin/python3.11 it seems to work form me as expected against 3.1 release tarball:

# fails as expected:
$ ./configure
...
checking for a Python interpreter with version >= 3.7... none
configure: error: no suitable Python interpreter found

# works as expected:
$ PYTHON=python3.11 ./configure
...
checking whether python3.11 version is >= 3.7... yes
checking for python3.11 version... 3.11
checking for python3.11 platform... linux
checking for GNU default python3.11 prefix... ${prefix}
checking for GNU default python3.11 exec_prefix... ${exec_prefix}
checking for python3.11 script directory (pythondir)... ${PYTHON_PREFIX}/lib/python3.11/site-packages
checking for python3.11 extension module directory (pyexecdir)... ${PYTHON_EXEC_PREFIX}/lib/python3.11/site-packages
...
$ make && make -j$(nproc) check
...
PASS: run_tests.py

How do you override default python? I wonder how it manages to fail version check.

@0-wiz-0
Copy link
Author

0-wiz-0 commented Aug 24, 2023

I think the first error I reported was caused by the build framework I'm using - please ignore it.
That's why I switched to the minimal environment for my second test.

Feel free to close this ticket.
(I have a patched automake, but I agree that we shouldn't have to rely on that and that upstream should make a release for that fix :))

@trofi
Copy link
Collaborator

trofi commented Sep 1, 2023

I requested new automake upstream release in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65679

@trofi
Copy link
Collaborator

trofi commented Sep 2, 2023

The upstream is not planning to release automake any time soon and is saying that new python-related code has other regressions.

Let's close this bug as there are easy workarounds available and proper fix belongs to automake.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants