Error building master

Error building master

[John Weber]

I've run into a problem building fsl-image-test.  It exits with the following:

| 
/home/john/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.8.1/ld: 
cannot find -lGL
| collect2: error: ld returned 1 exit status
| make: *** [libGLU.la] Error 1
| ERROR: oe_runmake failed
| ERROR: Function failed: do_compile (log file is located at 
/home/john/fsl-community-bsp/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/libglu/2_9.0.0-0/temp/log.do_compile.7553)
ERROR: Task 4474 
(/home/john/fsl-community-bsp/sources/poky/meta/recipes-graphics/mesa/libglu_9.0.0.bb, 
do_compile) failed with exit code '1'
NOTE: Tasks Summary: Attempted 2355 tasks of which 2351 didn't need to be rerun 
and 1 failed.
Waiting for 0 running tasks to finish:

Summary: 1 task failed:
 
/home/john/fsl-community-bsp/sources/poky/meta/recipes-graphics/mesa/libglu_9.0.0.bb, 
do_compile
Summary: There was 1 ERROR message shown, returning a non-zero exit code.

It appears that during the build of libGLU, it attempts to find a shared library 
named libGL.so somewhere in the library search path and it cannot find it.

The recipe DEPENDS on virtual/libgl, so I'm guessing that this library 'should' 
have been built prior to the building of libGLU.

Searching for the file libGL* in the build/tmp directory yields a number of results:

john@leo:~/fsl-community-bsp/build/tmp$ find . -name libGL*
~snip~
./work/wandboard_dual-poky-linux-gnueabi/mesa/2_9.1.3-r0/Mesa-9.1.3/lib/libGL.so
~snip~
./work/wandboard_dual-poky-linux-gnueabi/gpu-viv-bin-mx6q/1_3.0.35-4.0.0-r5.0/gpu-viv-bin-mx6q-3.0.35-4.0.0/usr/lib/libGL.so

Here is are the -L options from the build command as reported in log.do_compile.

-L/home/john/fsl-community-bsp/build/tmp/sysroots/wandboard-dual/lib
-L/home/john/fsl-community-bsp/build/tmp/sysroots/wandboard-dual/usr/lib/arm-poky-linux-gnueabi/4.8.1 

-L/home/john/fsl-community-bsp/build/tmp/sysroots/wandboard-dual/usr/lib

However, none of these paths contain a libGL.so file.  Based on the 
PREFERRED_PROVIDER_virtual/libgl_mx6 this 'should' be gpu-viv-bin-mx6q.  Is it 
possible that a  step is missing during do_install for gpu-viv-bin-mx6q or mesa? 
  I'm building for wandboard-dual.

Thanks,
John

Re: Error building master

[John Weber]

I ran into this problem again.  Again, I worked around it by manually copying 
the required libraries from gpu-viv-bin-mx6q to the sysroot location.

Here is some other information that I discovered tonight that might shed some 
light.  After I did the manual copy, I attempted to rebuild the image again. 
When I did, libglu compile succeeded, and bitbake produced some warning messages.

WARNING: The recipe gpu-viv-bin-mx6q is trying to install files into a shared 
area when those files already exist. Those files and their manifest location are:
 
/home/john/fsl-community-bsp/build/tmp/sysroots/wandboard-quad/usr/lib/libGL.so.1.2.0
 
/home/john/fsl-community-bsp/build/tmp/sysroots/wandboard-quad/usr/lib/libGLESv2.so.2
 
/home/john/fsl-community-bsp/build/tmp/sysroots/wandboard-quad/usr/lib/libGLESv1_CM.so.1
 
/home/john/fsl-community-bsp/build/tmp/sysroots/wandboard-quad/usr/lib/libGLESv2.so.2.0.0
 
/home/john/fsl-community-bsp/build/tmp/sysroots/wandboard-quad/usr/lib/libGLESv1_CL.so
 
/home/john/fsl-community-bsp/build/tmp/sysroots/wandboard-quad/usr/lib/libGL.so.1
 
/home/john/fsl-community-bsp/build/tmp/sysroots/wandboard-quad/usr/lib/libGLESv1_CL.so.1.1.0
 
/home/john/fsl-community-bsp/build/tmp/sysroots/wandboard-quad/usr/lib/libGLES_CM.so
 
/home/john/fsl-community-bsp/build/tmp/sysroots/wandboard-quad/usr/lib/libGLESv1_CM.so.1.1.0
 
/home/john/fsl-community-bsp/build/tmp/sysroots/wandboard-quad/usr/lib/libGLESv1_CM.so
 
/home/john/fsl-community-bsp/build/tmp/sysroots/wandboard-quad/usr/lib/libGLSLC.so
 
/home/john/fsl-community-bsp/build/tmp/sysroots/wandboard-quad/usr/lib/libGLES_CL.so
 
/home/john/fsl-community-bsp/build/tmp/sysroots/wandboard-quad/usr/lib/libGLESv2.so
 
/home/john/fsl-community-bsp/build/tmp/sysroots/wandboard-quad/usr/lib/libGLESv1_CL.so.1
 
/home/john/fsl-community-bsp/build/tmp/sysroots/wandboard-quad/usr/lib/libGL.so.1.2
    /home/john/fsl-community-bsp/build/tmp/sysroots/wandboard-quad/usr/lib/libGL.so
Please verify which package should provide the above files.

It seems that AFTER libglu finishes its build, the Vivante GPU recipe attempts 
to install its libraries to the sysroot.  Since libglu depends on those 
libraries, this looks like a build dependency problem.  I did verify that the 
preferred provide for libgl is the Vivante recipe.

John

On 7/5/13 10:01 PM, John Weber wrote:
> I've run into a problem building fsl-image-test.  It exits with the following:
>
> |
> /home/john/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.8.1/ld:
> cannot find -lGL
> | collect2: error: ld returned 1 exit status
> | make: *** [libGLU.la] Error 1
> | ERROR: oe_runmake failed
> | ERROR: Function failed: do_compile (log file is located at
> /home/john/fsl-community-bsp/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/libglu/2_9.0.0-0/temp/log.do_compile.7553)
>
> ERROR: Task 4474
> (/home/john/fsl-community-bsp/sources/poky/meta/recipes-graphics/mesa/libglu_9.0.0.bb,
> do_compile) failed with exit code '1'
> NOTE: Tasks Summary: Attempted 2355 tasks of which 2351 didn't need to be rerun
> and 1 failed.
> Waiting for 0 running tasks to finish:
>
> Summary: 1 task failed:
>
> /home/john/fsl-community-bsp/sources/poky/meta/recipes-graphics/mesa/libglu_9.0.0.bb,
> do_compile
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
>
> It appears that during the build of libGLU, it attempts to find a shared library
> named libGL.so somewhere in the library search path and it cannot find it.
>
> The recipe DEPENDS on virtual/libgl, so I'm guessing that this library 'should'
> have been built prior to the building of libGLU.
>
> Searching for the file libGL* in the build/tmp directory yields a number of
> results:
>
> john@leo:~/fsl-community-bsp/build/tmp$ find . -name libGL*
> ~snip~
> ./work/wandboard_dual-poky-linux-gnueabi/mesa/2_9.1.3-r0/Mesa-9.1.3/lib/libGL.so
> ~snip~
> ./work/wandboard_dual-poky-linux-gnueabi/gpu-viv-bin-mx6q/1_3.0.35-4.0.0-r5.0/gpu-viv-bin-mx6q-3.0.35-4.0.0/usr/lib/libGL.so
>
>
> Here is are the -L options from the build command as reported in log.do_compile.
>
> -L/home/john/fsl-community-bsp/build/tmp/sysroots/wandboard-dual/lib
> -L/home/john/fsl-community-bsp/build/tmp/sysroots/wandboard-dual/usr/lib/arm-poky-linux-gnueabi/4.8.1
>
> -L/home/john/fsl-community-bsp/build/tmp/sysroots/wandboard-dual/usr/lib
>
> However, none of these paths contain a libGL.so file.  Based on the
> PREFERRED_PROVIDER_virtual/libgl_mx6 this 'should' be gpu-viv-bin-mx6q.  Is it
> possible that a  step is missing during do_install for gpu-viv-bin-mx6q or mesa?
>   I'm building for wandboard-dual.
>
> Thanks,
> John

Re: Error building master

[Otavio Salvador]

On Wed, Jul 10, 2013 at 1:09 AM, John Weber <rjohnweber@gmail.com> wrote:
> I ran into this problem again.  Again, I worked around it by manually
> copying the required libraries from gpu-viv-bin-mx6q to the sysroot
> location.
>
> Here is some other information that I discovered tonight that might shed
> some light.  After I did the manual copy, I attempted to rebuild the image
> again. When I did, libglu compile succeeded, and bitbake produced some
> warning messages.
>

I never saw this build error. Any more info?


--
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: Error building master

[John Weber]

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.



On 7/12/13 8:49 AM, Otavio Salvador wrote:
> On Wed, Jul 10, 2013 at 1:09 AM, John Weber <rjohnweber@gmail.com> wrote:
>> I ran into this problem again.  Again, I worked around it by manually
>> copying the required libraries from gpu-viv-bin-mx6q to the sysroot
>> location.
>>
>> Here is some other information that I discovered tonight that might shed
>> some light.  After I did the manual copy, I attempted to rebuild the image
>> again. When I did, libglu compile succeeded, and bitbake produced some
>> warning messages.
>>
>
> I never saw this build error. Any more info?
>
>
> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://projetos.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
>

Re: Error building master

[Chris Tapp]

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.

> 
> 
> On 7/12/13 8:49 AM, Otavio Salvador wrote:
>> On Wed, Jul 10, 2013 at 1:09 AM, John Weber <rjohnweber@gmail.com> wrote:
>>> I ran into this problem again.  Again, I worked around it by manually
>>> copying the required libraries from gpu-viv-bin-mx6q to the sysroot
>>> location.
>>> 
>>> Here is some other information that I discovered tonight that might shed
>>> some light.  After I did the manual copy, I attempted to rebuild the image
>>> again. When I did, libglu compile succeeded, and bitbake produced some
>>> warning messages.
>>> 
>> 
>> I never saw this build error. Any more info?
>> 
>> 
>> --
>> Otavio Salvador                             O.S. Systems
>> http://www.ossystems.com.br        http://projetos.ossystems.com.br
>> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
>> 
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale

Chris Tapp

opensource@keylevel.com
www.keylevel.com

Re: Error building master

[Chris Tapp]

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

>> 
>> 
>> On 7/12/13 8:49 AM, Otavio Salvador wrote:
>>> On Wed, Jul 10, 2013 at 1:09 AM, John Weber <rjohnweber@gmail.com> wrote:
>>>> I ran into this problem again.  Again, I worked around it by manually
>>>> copying the required libraries from gpu-viv-bin-mx6q to the sysroot
>>>> location.
>>>> 
>>>> Here is some other information that I discovered tonight that might shed
>>>> some light.  After I did the manual copy, I attempted to rebuild the image
>>>> again. When I did, libglu compile succeeded, and bitbake produced some
>>>> warning messages.
>>>> 
>>> 
>>> I never saw this build error. Any more info?
>>> 
>>> 
>>> --
>>> Otavio Salvador                             O.S. Systems
>>> http://www.ossystems.com.br        http://projetos.ossystems.com.br
>>> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
>>> 
>> _______________________________________________
>> meta-freescale mailing list
>> meta-freescale@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-freescale
> 
> Chris Tapp
> 
> opensource@keylevel.com
> www.keylevel.com
> 
> 
> 
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale

Chris Tapp

opensource@keylevel.com
www.keylevel.com

Re: Error building master

[John Weber]

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@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.

John

Re: Error building master

[Chris Tapp]

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@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@keylevel.com
www.keylevel.com

Re: 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@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@keylevel.com
> www.keylevel.com
>
>
>