From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yh0-f48.google.com (mail-yh0-f48.google.com [209.85.213.48]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id D7687E01405 for ; Tue, 9 Jul 2013 21:09:38 -0700 (PDT) Received: by mail-yh0-f48.google.com with SMTP id z12so2579747yhz.7 for ; Tue, 09 Jul 2013 21:09:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=xC6mbFBagMWWLBSLqw+Lj/3fIsDpSHeyIDAzcQstUEQ=; b=xK0fJjdNFDNmQl2r/10naZodYZLQxV4dk8zaSJbYNjyPcaWRSH/ZNRp6qYQQ6iSqNA tWz/O0N1cBbUnuwXBnLe0rLPIhSgXaFXdCHT+pmmp3aGVY7R4KJzBt/0Ax3eS3x9c0Mu dKOA3pphcOFCOxeS/3E1ps9fkiavCjPzKJIGHtZsLpz0yQMIXJeugJuqLhCZZv/BWkpT rYyRVEYglxDSV2lskChg/67X+ardcYs4DSiLyAH5z5i+whtgvL/epgCEqubTqSwzUPhL jI8DXRvNdBzJYLuKPSLB1IaxmTxxB2Kx9AiEXqPjTieWfFqb9pJoJJY4+DVbzgLBLuVw nmZA== X-Received: by 10.236.135.81 with SMTP id t57mr16835620yhi.238.1373429377583; Tue, 09 Jul 2013 21:09:37 -0700 (PDT) Received: from goober.local ([75.76.228.60]) by mx.google.com with ESMTPSA id h26sm49942269yhb.21.2013.07.09.21.09.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 21:09:37 -0700 (PDT) Message-ID: <51DCDE80.6010600@gmail.com> Date: Tue, 09 Jul 2013 23:09:36 -0500 From: John Weber User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "meta-freescale@yoctoproject.org" References: <51D78881.7060509@gmail.com> In-Reply-To: <51D78881.7060509@gmail.com> Subject: Re: Error building master X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 04:09:41 -0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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