On Wed, Mar 16, 2016 at 5:23 PM, <[email protected]> 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 -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
