[meta-freescale] Error building master

[John Weber]

I'll file this one under meta-fsl-arm BSPs and reference the one you just filed, 
Chris.

On 7/12/13 4:58 PM, Chris Tapp wrote:
>
> On 12 Jul 2013, at 22:49, John Weber wrote:
>> On 7/12/13 3:10 PM, Chris Tapp wrote:
>>> On 12 Jul 2013, at 19:35, Chris Tapp wrote:
>>>
>>>> Hi John,
>>>>
>>>> On 12 Jul 2013, at 18:44, John Weber wrote:
>>>>
>>>>> I've synced the entire platform and am rebuilding all again to make sure I still see this error, but this was the second time I've seen it.  I'll report back.
>>>>
>>>> This looks to be the same as http://comments.gmane.org/gmane.linux.embedded.yocto.general/12533.
>>>>
>>>> I'm supposed to have opened a bug for this - I'll try and get it in later on today.
>>>
>>> Done - https://bugzilla.yoctoproject.org/show_bug.cgi?id=4848
>>>
>>
>> Thanks Chris.  It does look similar.  Here is another piece of information from today:
>>
>> Starting from a semi-clean build (new build/tmp, but with preexisting shared state cache), and a freshly updated set of metadata, I ran bitbake fsl-image-test, here is the header printout:
>>
>> john at leo:~/fsl-community-bsp/build$ MACHINE=wandboard-dual bitbake fsl-image-test
>> Loading cache: 100% |###########################################| ETA:  00:00:00
>> Loaded 1706 entries from dependency cache.
>>
>> Build Configuration:
>> BB_VERSION        = "1.19.1"
>> BUILD_SYS         = "x86_64-linux"
>> NATIVELSBSTRING   = "Ubuntu-12.04"
>> TARGET_SYS        = "arm-poky-linux-gnueabi"
>> MACHINE           = "wandboard-dual"
>> DISTRO            = "poky"
>> DISTRO_VERSION    = "1.4+snapshot-20130712"
>> TUNE_FEATURES     = "armv7a vfp neon"
>> TARGET_FPU        = "vfp-neon"
>> meta
>> meta-yocto        = "(nobranch):a63229917a5708de2d161aba0d67168ce0da6365"
>> meta-oe           = "(nobranch):c383d6230942bb1558cee02764bced09031cb70f"
>> meta-fsl-arm      = "master-next:e2f010bec19aef73b4731cb4f66c7412d59b265c"
>> meta-fsl-arm-extra = "(nobranch):3898b9dfa4bc81791665179d8854d47a5080060e"
>> meta-fsl-demos    = "(nobranch):eb6bd0d3e799c9053f80104194a0f2a37fb690e2"
>>
>> - I encountered the same exact issue with libglu (not able to find -lGL or libGL.so)
>> - Running bitbake gpu-viv-bin-mx6q followed by bitbake fsl-image-test worked to create an image
>>
>> I'm fairly sure that libGL.so is not being populated into the sysroot before libglu runs its do_compile task, so it seems to be a dependency problem to me. But others should see this problem as well and they are not.
>>
>> Then, I started from a brand new shared state cache and new build/tmp just to eliminate the possibility of any issues that could be part of my personal setup here.  I had the same result.
>>
>> Not sure what I can do if I'm the only person seeing this issue, besides file a bug on it.
>
> Sounds like it's worth filing. It certainly looks like there's something there and it makes sense to capture any information you've got.
>
>> John
>>
>
> Chris Tapp
>
> opensource at keylevel.com
> www.keylevel.com
>
>
>