[oe] [PATCH] flex: disabled packaged staging of native builds

Tom Rini tom_rini at mentor.com
Tue Aug 17 17:25:59 UTC 2010


Frans Meulenbroeks wrote:
> 2010/8/17 Jason Kridner <jkridner at beagleboard.org>:
>> On Mon, Aug 16, 2010 at 7:43 PM, Tom Rini <tom_rini at mentor.com> wrote:
>>> Jason Kridner wrote:
>>>> ---
>>>>  recipes/flex/flex.inc |    4 +++-
>>>>  1 files changed, 3 insertions(+), 1 deletions(-)
>>>>
>>>> diff --git a/recipes/flex/flex.inc b/recipes/flex/flex.inc
>>>> index 49b26e8..5d3f076 100644
>>>> --- a/recipes/flex/flex.inc
>>>> +++ b/recipes/flex/flex.inc
>>>> @@ -4,7 +4,7 @@ LICENSE = "BSD"
>>>>  DEPENDS = "gettext"
>>>>  -INC_PR = "r5"
>>>> +INC_PR = "r6"
>>>>  S = "${WORKDIR}/flex-${PV}"
>>>>  @@ -16,3 +16,5 @@ inherit autotools gettext
>>>>  # static-only library; that might be an error
>>>>  FILES_${PN} += "${libdir}/libfl.a"
>>>> +
>>>> +PSTAGING_DISABLED_virtclass-native = "1"
>>> I assume you've ran into 2.3.35 not being relocation happy?  Have you been
>>> able to look at this at all?  2.3.31 works so it's something 'bad' done
>>> upstream.  Thanks!
>> I did, but I didn't look into the details.  bison-native wouldn't
>> rebuild when I used my flex-native pstage.  bitbake -c clean
>> flex-native fixed it, so...
> 
> After that would rebuilding from pstage cause the error again?
> I'm a little bit worried that we inhibit PSTAGING because e.g.
> something else is wrong (e.g. a change elsewhere that should have been
> resulted in a flex PR bump).

So, this change is fine itself.  The problem is that flex 2.3.35 has 
introduced a hardcoded path somewhere into the binary.  So blacklisting 
and bumping PR means that pstaging is sane again.

> Besides (but this is more a global remark): it would be nice if a
> recipe disables something that there is a short description why this
> is done. (at least in the commit message, but imho preferably in the
> recipe, so in half a year time, people still know why it is done and
> can much easier judge if it can be removed).

Yes, I agree with that, a comment why is good.

-- 
Tom Rini
Mentor Graphics Corporation




More information about the Openembedded-devel mailing list