[OE-core] [PATCH]] python: Unbreak Python third-party extensions

Kamble, Nitin A nitin.a.kamble at intel.com
Mon May 2 16:57:18 UTC 2011


> > Op 29 apr 2011, om 12:44 heeft Michael Lippautz het volgende
> geschreven:
> >
> >> This fixes compilation/linking of Python 3rd party extensions.
> >>
> >> ${STAGING_LIBDIR}/python<pyver>/config/Makefile needs the correct
> >> INCDIR and LIBDIR settings to be used in cross compilation for the
> >> target. 3rd party module use distutils.sysconfig which uses this
> >> Makefile to create compiler/linker flags.
> >>
> >> Workflow:
> >> 1) compile needs the staged/sysroot Makefile since it is needed
> >>   for compilation/linking
> >> 2) install needs the unmodified Makefile to install files (i.e.
> >>   headers) into the right directores. (otherwise they would be
> >>   installed in ${D}/${STAGING_...}
> >> 3) staging needs modified Makefile again
> >> 4) packaging needs unmodified to make compilation on the target
> >>   possible
> >
> > Does any of the sysroot leak into the 3rd party extensions after this
> patch? Apart from that question, the patch looks good to me, although I
> needed a cup of coffee to work out the flow.
> 
> Nothing leaks into the 3rd party extensions as far as I know. The
> Makefile is used by distutils (i.e. distutils.sysconfig) to determine
> the compiler settings.
> 
> In the case of a 3rd partyextension the flow is as follows:
> * distutils.bbclass uses python-native + distutils-native to generate
> the package
> * distutils-native looks up the compiler settings via
> distutils.sysconfig (-native) in
> ${STAGING_LIBDIR}/python<pyver>/config/Makefile
>   (it is thus important that STAGING_LIBDIR is set by
> distutils.bbclass)
> * 3rd party extension is compiled using the settings from this Makefile
> 
> The compilation on the target should still be possible (although I
> didn't test it), because the target's Makefile is untouched.
> 
> The actual problem was that the targets Makefile did get staged and
> the compiler and linker have been invoked with the targets libs, for
> instance -L/usr/lib.
> 
> > regards,
> >
> > Koen
> 
> (I needed more than one coffee to figure out this flow)
> 
> -Michael

Michael,
   This patch is invasive for python recipe but looks fine to me. How much testing have you done? We have few python extensions in yocto repo, and none of them were hit by this issue. So which python extensions are seeing the issue?

Thanks,
Nitin


> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core




More information about the Openembedded-core mailing list