[oe] [oe-commits] org.oe.dev autotools.bbclass: from OM. Needed as commit 85a5e185b6a21e42e4243ad17befe40373025e0e alone will break uclibc/gettext builds.

Richard Purdie rpurdie at rpsys.net
Mon May 12 10:08:23 UTC 2008


On Mon, 2008-05-12 at 10:20 +0100, Graeme Gregory wrote:
> On Mon, May 12, 2008 at 02:17:23AM +0200, likewise commit wrote:
> > autotools.bbclass: from OM. Needed as commit 85a5e185b6a21e42e4243ad17befe40373025e0e alone will break uclibc/gettext builds.
> > 
> I was specifically asked not to merge this from OM to OE until more
> investigation was carried out.
> 
> > -		cp -fpPR "$from"/* "$to"
> > +		cp -fpPR -t "$to" "$from"/*
> >  
> Isnt this a reverse diff of a previous change for no real reason?

Yes, that reverts a fix that was made and is unrelated to the problem
you're trying to fix :(

> > -				echo "oe_libinstall -C ${S} -so $(basename $i .la) ${STAGING_LIBDIR}/${dir}"
> > -				oe_libinstall -C ${S} -so $(basename $i .la) ${STAGING_LIBDIR}/${dir}
> > +				echo "oe_libinstall -C ${STAGE_TEMP}/${libdir}/${dir} -so $(basename $i .la) ${STAGING_LIBDIR}/${dir}"
> > +				oe_libinstall -C ${STAGE_TEMP}/${libdir}/${dir} -so $(basename $i .la) ${STAGING_LIBDIR}/${dir}
> 
> And this section was under discussion with Holger, RP and myself.
> 
> I dont think this commit should have gone in without discussion.

and whilst this "fixes" certain issues, it will cause all kinds of other
subtle changes. What we don't know is whether that will result in
breakage or not. It hasn't for OpenMoko but that doesn't mean its the
right thing to do.  I doubt you've taken the time to understand what
this does and what the potential implications are :(.

I think the proper fix will be to stop using oe_libinstall entirely here
and instead do something like:

http://www.rpsys.net/openzaurus/temp/autotools.patch

This patch is as yet untested but I'll try and give it some testing...

Cheers,

Richard









More information about the Openembedded-devel mailing list