Re: [PATCH 02/24] python3-native: use the previous version of python-config script

["Andreas Müller" <schnitzeltony@googlemail.com>]

On Wed, Mar 16, 2016 at 5:23 PM,  <alexander.kanavin@linux.intel.com> wrote:
>>> Apologies for being terse. I should've explained that when building
>>> recipes that make use of this script, it will be run with the native
>>> python (instead of host python) because native python will come first in
>>> the PATH, and so the version reported will be correct, because native
>>> python will match target python. This is set up in pythonnative.bbclass
>>> for python 2, and in python3native.bbclass for python 3.
>> Sorry but I don't get it: The script reports the version of host's
>> python which might be different from what we are building native and
>> cross. When something is trying to link against python libs and is
>> using this script this crashes for host's with python < 3.5. This is a
>> bug. It should be either corrected or using of pkg-config should be
>> enforced if possible.
>
> The script reports the version of the host python, because you are running
> it with the host python. If you run it with the native python, it will
> report version of the native python. All recipes that need to execute
> python code as a part of their build are doing that, and therefore are
> getting the correct version.
This was the missing bit for me. Seems for some reason (qmake-native?
- see below) my recipe is running host's python.
> Where is the bug here? Can you demonstrate
> it? (by something else than running the script using host python,
> obviously)
>
> I agree that we should generally get rid of such custom,
> separately-maintained configuration scripts and migrate everything to
> pkgconfig, but that is a separate issue.
>
>> By the way: What was wrong with the shell script exactly? We have used
>> it for long time and it reported the correct version.
>
> The shell script was introduced with Python 3.4. All previous versions of
> python, including python 2.x, are using a different, python-based version
> of the script, to which we do some patching so that it reports things
> correctly in our cross-compilation environment. [1]
>
> The problem with the shell script is that it lacks those tweaks, and
> things break down when you try to build python3-based software with it.
> Specifically, I ran into issues building pygobject 3.x, and after trying
> to fix the shell script, I gave up and reverted to tried and tested
> python-based version - which is what this patch does. I believe the
> problem wasn't noticed earlier, because prior to pygobject 3.x there was
> no other python3-based software using python-config.
>
> Now you need to be exact: where and how did you use the shell script for a
> long time? Why should oe-core start using it, if it's known to be broken
> and requires patching?
>
Ok 'long time' was an assumption I have to regret but [1] first failed
when I updated 3.4 -> 3.5 (due to hard coded version in qmake pri -
file) and then failed again after updating to pythonic python3-config.
I know the fix I chose then is bad hack, but I tried to backport an
upstream solution and that failed for reasons we discuss here: linking
python3.4m which does not exist.

Thanks for explanation and sorry for shouting out - I'll rework that
recipe to use pkg-config as it is interested in version of python's
libraries - not the interpreter scripts are running on.

[1] https://github.com/schnitzeltony/meta-qt5-extra/blob/master/recipes-misc/recipes-cad/antimony/antimony_0.9.0c.bb

Andreas