[OE-core] WRL error: "Can't locate Config_heavy-target.pl in @INC" -- OE versus WRL

[Mark Hatle]

On 11/13/16 4:49 AM, Robert P. J. Day wrote:
> 
>   sorry, i'm still confused, let me make sure i understand this ...
> 
> On Sat, 12 Nov 2016, Mark Hatle wrote:
> 
>> On 11/12/16 2:45 PM, Robert P. J. Day wrote:
>>>
>>>   (note: this is actually an error i'm getting under wind river linux
>>> 8, i'm just curious as to why OE works just fine.)
>>>
>>>   as mentioned, when trying to build a trivial hand-rolled perl recipe
>>> under wind river linux 8, i'm getting:
>>>
>>> | Can't locate Config_heavy-target.pl in @INC (@INC contains: ... long
>>> path snipped ...) at
>>> .../tmp/sysroots/x86_64-linux/usr/lib/perl-native/perl/5.22.0/Config.pm
>>> line 88.
>>
>> My suspicion is that you are not using the buildtools-tarball with
>> your OE build, ...
> 
>   that would be correct, i've never used that, never needed to, on my
> fedora system. which means (correct me if i'm wrong) that i *am* using

You are using host content to build instead of the buildtools-tarball content.
(buildtools-tarball is supposed to include all of the host's tools necessary to
build a reasonable system with the correct versions.)

> some natively-installed content, based on ASSUME_PROVIDED from
> bitbake.conf. and i notice there's a few extra lines there than what i
> remember from quite some time back, including

All the assumed provide says is if anything requires one of those items, assume
it exists -- don't complain or try to build it.

>     hostperl-runtime-native \
> 
> so i'll have to look at what that means. but the point here is that
> the OE build *does* work.
> 
>> but Wind River Linux automatically uses this in an attempt to avoid
>> host incompatibilities with all of the random hosts our customers
>> use.
> 
>   ok, so WRL builds and uses the buildtools-tarball, and that's where
> i get the aforementioned error.

if there is a bug in the buildtools-tarball content (nativesdk packages) then it
can manifest itself like this.

>> To use the OE version of buildtools-tarball, you will have to build
>> it, extract it and then source the environment file.
> 
>   and that's where i'm confused ... i'm not using the OE version of
> buildtools-tarball with my OE build and things *work*, so why would i
> want to use it *now*? this seems backwards.

If your host is missing content and you don't have root access.. you don't have
a choice but to build the components yourself -- or the easier way to build and
use the buildtools-tarball.

A -lot- of commercial customers do not have root access on their build machines
(either at their desk or elsewhere).  So when they find something is missing,
say python3 or the right version or tar or make or git... they don't have any
easy way to fix the problem.  The buildtools-tarball content provides these and
other components.

>>>   but building precisely the same recipe under regular OE (actually,
>>> poky) works just fine. i did some searching, and found this:
>>>
>>> https://patchwork.openembedded.org/patch/111047/
>>>
>>> but i have no idea what it means. i also notice that the standard
>>> bitbake.conf (which i haven't looked at in a while), now contains a
>>> few more ASSUME_PROVIDED entries, including:
>>>
>>>     hostperl-runtime-native \
>>>     hostpython-runtime-native \
>>
>> f4dade8e meta/conf/bitbake.conf         (Ed Bartosh                2016-01-07
>> 13:39:39 +0200 179)     hostperl-runtime-native \
>> 8a474057 meta/conf/bitbake.conf         (Ed Bartosh                2016-01-13
>> 10:03:04 +0200 180)     hostpython-runtime-native \
>>
>> These are newer then Wind River Linux 8, which is based on Yocto Project 2.0 /
>> Jethro which was released around Nov 2015.
>>
>>> while the WRL version contains:
>>>
>>>     perl-native-runtime \
>>>     python-native-runtime \
>>
>> You you look at Jethro you will see:
>>
>> 34927dfa meta/conf/bitbake.conf         (Richard Purdie          2007-12-18
>> 15:04:06 +0000 174)     perl-native-runtime \
>> 34927dfa meta/conf/bitbake.conf         (Richard Purdie          2007-12-18
>> 15:04:06 +0000 175)     python-native-runtime \
>>
>> So you are attempting to compare apples to oranges (master/morty/krogoth against
>> jethro.)
> 
>   so ... what is the solution here? how would i tweak my WRL build to
> resolve this issue? again, apologies for asking a WRL question on the
> OE list, i'm just trying to understand the difference.

First if you are comparing any commercial embedded Linux to OE, be sure to be
comparing the same version.  In this case WRL 8 to master, morty or krogoth is
not a reasonable comparison as it is based on Jethro.  (The commercial vendor
will be able to tell you what version they are based on.)

If you are having a specific problem with a commercial distribution you should
contact them for support.  Our support organization can help you determine if
it's a usage problem, or something broken in our product.

I've not run across this issue, so I can't help any further on the product side.

--Mark

> rday
>