On the back of trying to build Xen 4.12.2 on an LFS system, I've
hit an issue whereby the Xen M4 python_devel module fails but,
even when I fix that, Python3 seems to report the "wrong" info.

I am asking similar questions, albeit with more of a Xen focus,
on the Xen developers list.

The first issue is that Xen's M4 python_devel module tries to
get a version number for "$PYTHON" by doing

> head ../m4/python_devel.m4
AC_DEFUN([AX_CHECK_PYTHON_DEVEL], [
ac_previous_cppflags=$CPPFLAGS
ac_previous_ldflags=$LDFLAGS
ac_python_version=`$PYTHON -c 'import distutils.sysconfig; \
    print distutils.sysconfig.get_config_var("VERSION")'`
AC_PATH_PROG([pyconfig], [$PYTHON-config], [no])
...


That fails as follows

...
checking for unistd.h... yes
  File "<string>", line 1
    import distutils.sysconfig;     print distutils.sysconfig.get_config_var("VE
RSION")

                                                  ^
SyntaxError: invalid syntax
checking for python3-config... /usr/bin/python3-config
..


If we check out the command in an interactive interpeter session,
we can identify the problen here, vis


> python3
Python 3.7.4 (default, Nov 17 2019, 18:19:17)
[GCC 9.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import distutils.sysconfig
>>> distutils.sysconfig.get_config_var("VERSION")
'3.7'
>>>
>>> print distutils.sysconfig.get_config_var("VERSION")'
  File "<stdin>", line 1
    print distutils.sysconfig.get_config_var("VERSION")'
>>> print(distutils.sysconfig.get_config_var("VERSION"))
3.7
>>> quit()

which suggests that the issue comes from the "print" statement,
not the distutils module.


It is fairly easy to fix the syntax there, by patching Xen's
M4 python_devel module to have parentheses around the argument
to the print command, vis:


ac_python_version=`$PYTHON -c 'import distutils.sysconfig; \
    print(distutils.sysconfig.get_config_var("VERSION"))'`


however,  now that the Python interpreter is returning "3.7"
as the "version", Xen's configure script goes on to run some
tests as follows

...
checking for unistd.h... yes
checking for python3-config... /usr/bin/python3-config
checking Python.h usability... yes
checking Python.h presence... yes
checking for Python.h... yes
checking for PyArg_ParseTuple in -lpython3.7... no
configure: error: Unable to find a suitable python development library
configure: error: ./configure failed for tools

and here the actual (from tools/config.log) command that's being
run as the test


configure:7456: checking for PyArg_ParseTuple in -lpython3.7
configure:7481: gcc -o conftest -g -O2 -g -O2 \
 -I/usr/include/python3.7m -I/usr/include/python3.7m  \
 -Wno-unused-result -Wsign-compare  -DNDEBUG -g -fwrapv \
 -O3 -Wall     -L/usr/lib -lpython3.7m -lcrypt -lpthread \
 -ldl  -lutil -lm  conftest.c -lpython3.7  -lpython3.7m \
 -lcrypt -lpthread -ldl  -lutil -lm   >&5
/usr/bin/ld: cannot find -lpython3.7



So here's the issue:

in LFS 9.0, Section 6.51, Python-3.7.4 we read

  6.51.2. Contents of Python 3

  Installed Programs: 2to3, idle3, pip3, pydoc3, python3, python3-config,
    and pyvenv

  Installed Library: libpython3.7m.so and libpython3.so

  Installed Directories: /usr/include/python3.7m, /usr/lib/python3
    and /usr/share/doc/python-3.7.4

but, on the LFS system, we have

> ls -o /usr/lib/libpython3.*
lrwxrwxrwx 1 python3      20 Nov 17 18:20 /usr/lib/libpython3.7m.so -> libpython
3.7m.so.1.0
-rwxr-xr-x 1 python3 3265256 Nov 17 20:10 /usr/lib/libpython3.7m.so.1.0
-rwxr-xr-x 1 python3   13984 Nov 17 20:10 /usr/lib/libpython3.so


So why, if the distutils module returns the version as "3.7"
do the Python installation have the extra "m" on the names
of its shared libraries ?

It's fairly easy to add a link

   /usr/lib/libpython3.7.so -> libpython3.7m.so.1.0

that will see what Python's distutils module tells Xen it's version
is match with the library that Xen then decides it should be looking
for, but it just strikes me as odd that the "m" is there in the first
place.

Not suggesting that LFS needs to add the "un-emm-ed" link, but maybe a
note to the effect that if one relies on Python's distutils module version
values, one might go on to construct the wrong library name.


Kevin
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Reply via email to