Python 3.10 configure error

[dg98]

Hello,
I was trying to build ZFS 2.1.0_rc5 on Gentoo with Python 3.10 installed but configure detects it as <= Python 3.4. When running configure through the ebuild, I get the following:

checking for python version... 3.1
checking for python platform... linux
checking for python script directory... ${prefix}/lib/python3.10/site-packages
checking for python extension module directory... ${exec_prefix}/lib/python3.10/site-packages
configure: error: "Python >= 3.4 is required"

So it somehow turns 3.10 into 3.1. If I clone the repo and run configure there, it prints 3.10 but the check for >= '3.4.0' still prints no:

checking for python3... python3
checking for python version... 3.10
checking for python platform... linux
checking for python script directory... ${prefix}/lib/python3.10/site-packages
checking for python extension module directory... ${exec_prefix}/lib/python3.10/site-packages
checking for python3.10... /usr/bin/python3.10
checking for a version of Python >= '2.1.0'... yes
checking for a version of Python >= '3.4.0'... no

[rincebrain]

I found the problem in git master (the conditional appears to be backwards and just worked because it parsed the filename of the interpreter, and many people just have "python3", so it didn't extract a version from that...); I haven't looked at 2.1-rc5 yet.

edit: Hm, I may have been looking at the wrong conditional, nevermind, I'll wait and get back to you when I have a working fix.

[rincebrain]

On my git master clone (7457b02), on Ubuntu 21.04, with Python 3.10.0a7-3, invoked by ./configure --enable-pyzfs --with-python=`which python3.10` the check you're lamenting correctly reports 3.10. (A later check fails, but that's not your current problem.) Can you share what grep -i python config.log says for yours?

[dg98]

Here you go:

config-python.log

[rincebrain]

That log seems to be spitting out the message I'm working on #12073 to solve, not the one you opened this bug about?

[dg98]

It seems like I copied the same text twice in my initial comment, I updated the second one now. Sorry for that

[rincebrain]

Okay, well, if you want, you can grab my PR in #12073 in the meantime to get this working with git master for you. I'll take a look at why 2.1-rc5 is behaving differently when I get a second, because I'm pretty sure the logic it should be using hasn't changed in years at this point.

[ahesford]

@rincebrain your patch does not fix the issue. Configuration fails because https://github.com/openzfs/zfs/blob/master/config/ax_python_devel.m4#L227 relies on sys.version[:3], which returns 3.1 on Python 3.10. The right fix here is doing something like

'.'.join(sys.version.split('.')[:2])

Making this change in config/ax_python_devel.m4 does not seem to be sufficient, since autoreconf can still grab the macro from a still-buggy installation of automake.

[thesamesam]

(Nit: not automake, but autoconf-archive).

[rincebrain]

@rincebrain your patch does not fix the issue. Configuration fails because https://github.com/openzfs/zfs/blob/master/config/ax_python_devel.m4#L227 relies on sys.version[:3], which returns 3.1 on Python 3.10. The right fix here is doing something like

'.'.join(sys.version.split('.')[:2])

Making this change in config/ax_python_devel.m4 does not seem to be sufficient, since autoreconf can still grab the macro from a still-buggy installation of automake.

Huh. I swear I did test that this not only ran but that the check succeeded. Wonder where I went wrong.

I'll go look.

[rincebrain]

@rincebrain your patch does not fix the issue. Configuration fails because https://github.com/openzfs/zfs/blob/master/config/ax_python_devel.m4#L227 relies on sys.version[:3], which returns 3.1 on Python 3.10. The right fix here is doing something like

'.'.join(sys.version.split('.')[:2])

Making this change in config/ax_python_devel.m4 does not seem to be sufficient, since autoreconf can still grab the macro from a still-buggy installation of automake.

...what environment are you on that you got to that codepath? Because on my Fedora Rawhide system, for example, that codepath doesn't get hit.

[ahesford]

The issue is the version of the automake package that pulls this macro. Apparently this is fixed in v1.16.4 (not sure about 1.16.3). The package I'm using, in Void, is 1.16.2. Looks like I can couple an automake update with py3.10 and resolve this problem.

[ThomasD13]

The issue is the version of the automake package that pulls this macro. Apparently this is fixed in v1.16.4 (not sure about 1.16.3). The package I'm using, in Void, is 1.16.2. Looks like I can couple an automake update with py3.10 and resolve this problem.

@ahesford : Hi, I have still the problem of wrong detection of the installed python version on my host. I tried zfs version 2.1.9, I installed python-3.11 on my system.
The configure step always detects python 3.1 and then stops.
You also mentioned that this could be a problem with automake.
My automake version is 1.16.5-1.3.
My host is a ubuntu 22.04 (jammy).

Do you have any suggestions what I can do, to solve this python version problem?

Update:
I fixed the issue. Problem was not my host, but the native automake which yocto have been used buildling zfs. I updated automake (autotools package at yocto) from 1.16.1 to 1.16.3. Thanks everyone for providing all the required information.

[kabu1204]

All works well after changing the line:

am_cv_python_version=`$PYTHON -c "import sys; sys.stdout.write(sys.version[:3])"`

to:

am_cv_python_version=`$PYTHON -c "import sys; sys.stdout.write(sys.version[:4])"`

in configure.

If your python version is >= 3.10, you can try this.