Re: [yocto] [RMC][PATCH v2] RMC: Support x32 build

[Khor, Swee Aun]

Okay. I will drop this patch. 

SweeAun

-Original Message-
From: Todor Minchev [mailto:todor.minc...@linux.intel.com] 
Sent: Friday, July 7, 2017 4:08 AM
To: Khor, Swee Aun 
Cc: yocto@yoctoproject.org; Wold, Saul 
Subject: Re: [RMC][PATCH v2] RMC: Support x32 build

On Wed, 2017-07-05 at 12:39 -0700, swee.aun.k...@intel.com wrote:
> From: sweeaun 
> 
> RMC efi is needed to compiled as 64 bits even DEFAULTTUNE is x32.
> 
> Signed-off-by: sweeaun 
> ---
>  Makefile.efi | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Makefile.efi b/Makefile.efi index 4f69dfe..95e0f8c 100644
> --- a/Makefile.efi
> +++ b/Makefile.efi
> @@ -16,6 +16,9 @@ RMC_INSTALL_LIB_PATH := $(RMC_INSTALL_PREFIX)/lib/
>  
>  RMC_CFLAGS := -DRMC_EFI -Wall -I$(TOPDIR)/inc -fpic -nostdinc 
> -nostdlib  -fno-builtin -std=gnu90
>  
> +#RMC efi is needed to be compiled as 64 bit even DEFAULTTUNE is x32 
> +CC := $(patsubst -mx32, -m64, $(CC))
> +

Since this is not an RMC-specific problem, I believe that we shouldn't patch 
the compiler flags in the RMC Makefile. This patch will provide the desired 
outcome only when RMC is built with meta-intel. A better alternative will be to 
split rmc.bb into rmc.bb (userspace app) and rmc-efi.bb (efi library) and 
modify the compiler flags for each recipe.
I will send a patch that does this.

Todor

>  all: librmcefi
>  
>  $(RMC_LIB_OBJ): %.efi.o: %.c


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [RMC][PATCH v2] RMC: Support x32 build

[swee . aun . khor]

From: sweeaun 

RMC efi is needed to compiled as 64 bits even DEFAULTTUNE is x32.

Signed-off-by: sweeaun 
---
 Makefile.efi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Makefile.efi b/Makefile.efi
index 4f69dfe..95e0f8c 100644
--- a/Makefile.efi
+++ b/Makefile.efi
@@ -16,6 +16,9 @@ RMC_INSTALL_LIB_PATH := $(RMC_INSTALL_PREFIX)/lib/
 
 RMC_CFLAGS := -DRMC_EFI -Wall -I$(TOPDIR)/inc -fpic -nostdinc -nostdlib  
-fno-builtin -std=gnu90
 
+#RMC efi is needed to be compiled as 64 bit even DEFAULTTUNE is x32 
+CC := $(patsubst -mx32, -m64, $(CC))
+
 all: librmcefi
 
 $(RMC_LIB_OBJ): %.efi.o: %.c
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] RMC: Support x32 build

[swee . aun . khor]

From: sweeaun 

RMC efi is needed to compiled as 64 bits even DEFAULTTUNE is x32.

Signed-off-by: sweeaun 
---
 Makefile.efi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Makefile.efi b/Makefile.efi
index 4f69dfe..95e0f8c 100644
--- a/Makefile.efi
+++ b/Makefile.efi
@@ -16,6 +16,9 @@ RMC_INSTALL_LIB_PATH := $(RMC_INSTALL_PREFIX)/lib/
 
 RMC_CFLAGS := -DRMC_EFI -Wall -I$(TOPDIR)/inc -fpic -nostdinc -nostdlib  
-fno-builtin -std=gnu90
 
+#RMC efi is needed to be compiled as 64 bit even DEFAULTTUNE is x32 
+CC := $(patsubst -mx32, -m64, $(CC))
+
 all: librmcefi
 
 $(RMC_LIB_OBJ): %.efi.o: %.c
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Problem with Module Dependency

[Jason Liu]

Dear all,

Right now I am developing driver for a camera. The camera module depends on
the omap3-isp module. Most of the times the camera drive will load before
the image signal processor module is loaded thus the camera won't function
properly.

For the developing version of the driver, I use usleep_range to force it to
sleep for couple seconds but obviously it is not a good solution.

Would you have any solution that I can make sure it gets loaded after all
dependencies is loaded properly? I am thinking a way to add something in
the driver that checks if the module is available or not but I couldn't
come up with one.

Any help is greatly appreciate!

Regards,

Jason
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [RMC][PATCH v2] RMC: Support x32 build

[Khem Raj]

On Thu, Jul 6, 2017 at 3:46 PM, Minchev, Todor  wrote:
> On Thu, 2017-07-06 at 13:46 -0700, Todor Minchev wrote:
>> On Thu, 2017-07-06 at 13:37 -0700, Khem Raj wrote:
>> > On Thu, Jul 6, 2017 at 1:08 PM, Todor Minchev
>> >  wrote:
>> > > On Wed, 2017-07-05 at 12:39 -0700, swee.aun.k...@intel.com wrote:
>> > >> From: sweeaun 
>> > >>
>> > >> RMC efi is needed to compiled as 64 bits even DEFAULTTUNE is x32.
>> > >>
>> > >> Signed-off-by: sweeaun 
>> > >> ---
>> > >>  Makefile.efi | 3 +++
>> > >>  1 file changed, 3 insertions(+)
>> > >>
>> > >> diff --git a/Makefile.efi b/Makefile.efi
>> > >> index 4f69dfe..95e0f8c 100644
>> > >> --- a/Makefile.efi
>> > >> +++ b/Makefile.efi
>> > >> @@ -16,6 +16,9 @@ RMC_INSTALL_LIB_PATH := $(RMC_INSTALL_PREFIX)/lib/
>> > >>
>> > >>  RMC_CFLAGS := -DRMC_EFI -Wall -I$(TOPDIR)/inc -fpic -nostdinc 
>> > >> -nostdlib  -fno-builtin -std=gnu90
>> > >>
>> > >> +#RMC efi is needed to be compiled as 64 bit even DEFAULTTUNE is x32
>> > >> +CC := $(patsubst -mx32, -m64, $(CC))
>> > >> +
>> > >
>> >
>> > does this mean package is overriding CC passed from env ?
>> > if yes then I think app should be fixed to respect CC if set in env
>> > and only set it if CC env is not set
>>
>> +1
>>
>> The app respects both CC and CFLAGS from the env. They have to be set to
>> the correct values before the Makefile is called.
>>
>> >
>> > > Since this is not an RMC-specific problem, I believe that we shouldn't
>> > > patch the compiler flags in the RMC Makefile. This patch will provide
>> > > the desired outcome only when RMC is built with meta-intel. A better
>> > > alternative will be to split rmc.bb into rmc.bb (userspace app) and
>> > > rmc-efi.bb (efi library) and modify the compiler flags for each recipe.
>> > > I will send a patch that does this.
>
> This patch should fix the x32 builds.
>
> https://lists.yoctoproject.org/pipermail/meta-intel/2017-July/004818.html
>

you could use TUNE_CCARGS_remove = "xyz" instead of anonymous python

> --Todor
>
>> > >
>> > >>  all: librmcefi
>> > >>
>> > >>  $(RMC_LIB_OBJ): %.efi.o: %.c
>> > >
>> > >
>> > > --
>> > > ___
>> > > yocto mailing list
>> > > yocto@yoctoproject.org
>> > > https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [RMC][PATCH v2] RMC: Support x32 build

[Minchev, Todor]

On Thu, 2017-07-06 at 13:46 -0700, Todor Minchev wrote:
> On Thu, 2017-07-06 at 13:37 -0700, Khem Raj wrote:
> > On Thu, Jul 6, 2017 at 1:08 PM, Todor Minchev
> >  wrote:
> > > On Wed, 2017-07-05 at 12:39 -0700, swee.aun.k...@intel.com wrote:
> > >> From: sweeaun 
> > >>
> > >> RMC efi is needed to compiled as 64 bits even DEFAULTTUNE is x32.
> > >>
> > >> Signed-off-by: sweeaun 
> > >> ---
> > >>  Makefile.efi | 3 +++
> > >>  1 file changed, 3 insertions(+)
> > >>
> > >> diff --git a/Makefile.efi b/Makefile.efi
> > >> index 4f69dfe..95e0f8c 100644
> > >> --- a/Makefile.efi
> > >> +++ b/Makefile.efi
> > >> @@ -16,6 +16,9 @@ RMC_INSTALL_LIB_PATH := $(RMC_INSTALL_PREFIX)/lib/
> > >>
> > >>  RMC_CFLAGS := -DRMC_EFI -Wall -I$(TOPDIR)/inc -fpic -nostdinc -nostdlib 
> > >>  -fno-builtin -std=gnu90
> > >>
> > >> +#RMC efi is needed to be compiled as 64 bit even DEFAULTTUNE is x32
> > >> +CC := $(patsubst -mx32, -m64, $(CC))
> > >> +
> > >
> > 
> > does this mean package is overriding CC passed from env ?
> > if yes then I think app should be fixed to respect CC if set in env
> > and only set it if CC env is not set
> 
> +1
> 
> The app respects both CC and CFLAGS from the env. They have to be set to
> the correct values before the Makefile is called.
>   
> > 
> > > Since this is not an RMC-specific problem, I believe that we shouldn't
> > > patch the compiler flags in the RMC Makefile. This patch will provide
> > > the desired outcome only when RMC is built with meta-intel. A better
> > > alternative will be to split rmc.bb into rmc.bb (userspace app) and
> > > rmc-efi.bb (efi library) and modify the compiler flags for each recipe.
> > > I will send a patch that does this.

This patch should fix the x32 builds.

https://lists.yoctoproject.org/pipermail/meta-intel/2017-July/004818.html

--Todor

> > >
> > >>  all: librmcefi
> > >>
> > >>  $(RMC_LIB_OBJ): %.efi.o: %.c
> > >
> > >
> > > --
> > > ___
> > > yocto mailing list
> > > yocto@yoctoproject.org
> > > https://lists.yoctoproject.org/listinfo/yocto
> 
> 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [RMC][PATCH v2] RMC: Support x32 build

[Todor Minchev]

On Thu, 2017-07-06 at 13:37 -0700, Khem Raj wrote:
> On Thu, Jul 6, 2017 at 1:08 PM, Todor Minchev
>  wrote:
> > On Wed, 2017-07-05 at 12:39 -0700, swee.aun.k...@intel.com wrote:
> >> From: sweeaun 
> >>
> >> RMC efi is needed to compiled as 64 bits even DEFAULTTUNE is x32.
> >>
> >> Signed-off-by: sweeaun 
> >> ---
> >>  Makefile.efi | 3 +++
> >>  1 file changed, 3 insertions(+)
> >>
> >> diff --git a/Makefile.efi b/Makefile.efi
> >> index 4f69dfe..95e0f8c 100644
> >> --- a/Makefile.efi
> >> +++ b/Makefile.efi
> >> @@ -16,6 +16,9 @@ RMC_INSTALL_LIB_PATH := $(RMC_INSTALL_PREFIX)/lib/
> >>
> >>  RMC_CFLAGS := -DRMC_EFI -Wall -I$(TOPDIR)/inc -fpic -nostdinc -nostdlib  
> >> -fno-builtin -std=gnu90
> >>
> >> +#RMC efi is needed to be compiled as 64 bit even DEFAULTTUNE is x32
> >> +CC := $(patsubst -mx32, -m64, $(CC))
> >> +
> >
> 
> does this mean package is overriding CC passed from env ?
> if yes then I think app should be fixed to respect CC if set in env
> and only set it if CC env is not set

+1

The app respects both CC and CFLAGS from the env. They have to be set to
the correct values before the Makefile is called.
  
> 
> > Since this is not an RMC-specific problem, I believe that we shouldn't
> > patch the compiler flags in the RMC Makefile. This patch will provide
> > the desired outcome only when RMC is built with meta-intel. A better
> > alternative will be to split rmc.bb into rmc.bb (userspace app) and
> > rmc-efi.bb (efi library) and modify the compiler flags for each recipe.
> > I will send a patch that does this.
> >
> > Todor
> >
> >>  all: librmcefi
> >>
> >>  $(RMC_LIB_OBJ): %.efi.o: %.c
> >
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [RMC][PATCH v2] RMC: Support x32 build

[Khem Raj]

On Thu, Jul 6, 2017 at 1:08 PM, Todor Minchev
 wrote:
> On Wed, 2017-07-05 at 12:39 -0700, swee.aun.k...@intel.com wrote:
>> From: sweeaun 
>>
>> RMC efi is needed to compiled as 64 bits even DEFAULTTUNE is x32.
>>
>> Signed-off-by: sweeaun 
>> ---
>>  Makefile.efi | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/Makefile.efi b/Makefile.efi
>> index 4f69dfe..95e0f8c 100644
>> --- a/Makefile.efi
>> +++ b/Makefile.efi
>> @@ -16,6 +16,9 @@ RMC_INSTALL_LIB_PATH := $(RMC_INSTALL_PREFIX)/lib/
>>
>>  RMC_CFLAGS := -DRMC_EFI -Wall -I$(TOPDIR)/inc -fpic -nostdinc -nostdlib  
>> -fno-builtin -std=gnu90
>>
>> +#RMC efi is needed to be compiled as 64 bit even DEFAULTTUNE is x32
>> +CC := $(patsubst -mx32, -m64, $(CC))
>> +
>

does this mean package is overriding CC passed from env ?
if yes then I think app should be fixed to respect CC if set in env
and only set it if CC env is not set

> Since this is not an RMC-specific problem, I believe that we shouldn't
> patch the compiler flags in the RMC Makefile. This patch will provide
> the desired outcome only when RMC is built with meta-intel. A better
> alternative will be to split rmc.bb into rmc.bb (userspace app) and
> rmc-efi.bb (efi library) and modify the compiler flags for each recipe.
> I will send a patch that does this.
>
> Todor
>
>>  all: librmcefi
>>
>>  $(RMC_LIB_OBJ): %.efi.o: %.c
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [RMC][PATCH v2] RMC: Support x32 build

[Todor Minchev]

On Wed, 2017-07-05 at 12:39 -0700, swee.aun.k...@intel.com wrote:
> From: sweeaun 
> 
> RMC efi is needed to compiled as 64 bits even DEFAULTTUNE is x32.
> 
> Signed-off-by: sweeaun 
> ---
>  Makefile.efi | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Makefile.efi b/Makefile.efi
> index 4f69dfe..95e0f8c 100644
> --- a/Makefile.efi
> +++ b/Makefile.efi
> @@ -16,6 +16,9 @@ RMC_INSTALL_LIB_PATH := $(RMC_INSTALL_PREFIX)/lib/
>  
>  RMC_CFLAGS := -DRMC_EFI -Wall -I$(TOPDIR)/inc -fpic -nostdinc -nostdlib  
> -fno-builtin -std=gnu90
>  
> +#RMC efi is needed to be compiled as 64 bit even DEFAULTTUNE is x32 
> +CC := $(patsubst -mx32, -m64, $(CC))
> +

Since this is not an RMC-specific problem, I believe that we shouldn't
patch the compiler flags in the RMC Makefile. This patch will provide
the desired outcome only when RMC is built with meta-intel. A better
alternative will be to split rmc.bb into rmc.bb (userspace app) and
rmc-efi.bb (efi library) and modify the compiler flags for each recipe.
I will send a patch that does this.

Todor

>  all: librmcefi
>  
>  $(RMC_LIB_OBJ): %.efi.o: %.c


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [yocto-autobuilder][PATCH V4 1/1] ScrapeTargets.py: improve target search algorithm

[Joshua Lock]

On Thu, 2017-07-06 at 08:09 -0700, Stephano Cetola wrote:
> On 07/06, Joshua Lock wrote:
> > This still leaves us a bit brittle. What if someone adds whitespace
> > around the assignment operator? Could you create a follow-on patch
> > for
> > that?
> > 
> > Thanks!
> 
> Actually, since the awk command just searches for self.targetsvar now
> instead of ``self.targetsvar="``, it will match even if there are
> spaces between the equal.

Context is important. It's not the awk command, it's the str.replace()

> +targets = targets.replace('%s="' % self.targetsvar, '')

we're going replace 'SOMEVARIABLE="' with '', but what if we get
'SOMEVARIABLE = "' ?

> I did just realize that if the variable is NOT multi-line, e.g.
> REFKIT_CI_POSTBUILD_SELFTESTS, this search will fail because of the
> "next" command.

Ah, yes. That could cause some surprises.

> I'll puzzle over this a bit.

Thanks!

Joshua
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [yocto-autobuilder][PATCH V4 1/1] ScrapeTargets.py: improve target search algorithm

[Stephano Cetola]

On 07/06, Joshua Lock wrote:
> This still leaves us a bit brittle. What if someone adds whitespace
> around the assignment operator? Could you create a follow-on patch for
> that?
> 
> Thanks!
Actually, since the awk command just searches for self.targetsvar now
instead of ``self.targetsvar="``, it will match even if there are
spaces between the equal.

I did just realize that if the variable is NOT multi-line, e.g.
REFKIT_CI_POSTBUILD_SELFTESTS, this search will fail because of the
"next" command.

I'll puzzle over this a bit.

-S
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Perforce fetcher ignores module and label

[Katu Txakur]

Hi,

I'm upgrading a recipe that fetches the source code from Perforce.

The old recipe was:

SRC_URI = " \
  
p4://${P4USER}:${P4PASSWD}:${P4HOST}:${P4PORT}@Depot/path/perforce/...;module=local/path/relativeto/p4;label=${P4CHANGELIST}
\
  "

With the new version of /lib/bb/fetch2/perforce.py, I had to set P4PORT
outside SRC_URI, leaving the recipe with:

SRC_URI = " \
  
p4://${P4USER}:${P4PASSWD}@Depot/path/perforce/...;module=local/path/relativeto/p4;label=${P4CHANGELIST}
\
  "

The Perforce fetcher kind of works, but it seems to be ignoring the
"module" and the "label" attributes. After reading the Python script I can
see that after the "@", only the substring before the first ";" is used.

Is there a way to set module and label/changelist? I have several folders
per recipe that I need to map to different subfolders and with the current
script some of the folders don't get fetched.

Thanks for your time.

Regards,
Katu
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [yocto-autobuilder][PATCH V4 1/1] ScrapeTargets.py: improve target search algorithm

[Joshua Lock]

On Wed, 2017-07-05 at 14:27 -0700, Stephano Cetola wrote:
> When scraping the build targets from refkit-ci.inc, grep would only
> return the first line of the search result. By replacing grep with
> awk, we are now searching for multi-line variables, and should now
> scrape build targets even if they have line breaks between them.
> 
> [YOCTO #11720]

Thanks, I've merged and pushed this. Please see my comment below.

> 
> Signed-off-by: Stephano Cetola 
> ---
>  .../site-packages/autobuilder/buildsteps/ScrapeTargets.py| 12
> +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/lib/python2.7/site-
> packages/autobuilder/buildsteps/ScrapeTargets.py
> b/lib/python2.7/site-packages/autobuilder/buildsteps/ScrapeTargets.py
> index 80153fe85..07e2fdcf4 100644
> --- a/lib/python2.7/site-
> packages/autobuilder/buildsteps/ScrapeTargets.py
> +++ b/lib/python2.7/site-
> packages/autobuilder/buildsteps/ScrapeTargets.py
> @@ -41,7 +41,9 @@ class ScrapeTargets(ShellCommand):
>  workerdir = os.path.join(os.path.join(YOCTO_ABBASE, "yocto-
> worker"))
>  buildername = self.getProperty("buildername")
>  src = os.path.join(workerdir, buildername, "build",
> self.source)
> -self.command = "cat " + src + " | grep " + self.targetsvar
> +# find targetsvar then return lines up to a quote
> +self.command = ["awk",
> +'/%s/{flag=1;print;next}/"/{flag=0}flag' %
> self.targetsvar, src]
>  ShellCommand.start(self)
>  
>  def commandComplete(self, cmd):
> @@ -49,10 +51,10 @@ class ScrapeTargets(ShellCommand):
>  return
>  
>  result = cmd.logs['stdio'].getText()
> -targets = result.replace(self.targetsvar, "")
> -targets = targets.strip()
> -targets = targets.replace('=', '')
> -targets = targets.strip('"')
> +targets = result.strip()
> +targets = targets.replace('%s="' % self.targetsvar, '')

This still leaves us a bit brittle. What if someone adds whitespace
around the assignment operator? Could you create a follow-on patch for
that?

Thanks!

> +targets = targets.replace('\\', '')
> +targets = targets.replace('\n', '')
>  self.setProperty("scraped_targets",
>   targets,
>   'Targets "%s" scraped from %s' % (targets,
> -- 
> 2.13.2
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] 403 error when trying to download toolchain

[Babushkin, Andrey]

Hi all!
I am trying to download toolchain for Yocto 2.0.3 here 
http://downloads.yoctoproject.org/releases/yocto/yocto-2.0.3/toolchain/ , but I 
get 403 Forbidden error. Is there any other places to download toolchain for 
Yocto 2.0.3?

---
Best regards,
Andrey Babushkin



Joint Stock Company Intel A/O
Registered legal address: Krylatsky Hills Business Park,
17 Krylatskaya Str., Bldg 4, Moscow 121614,
Russian Federation

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] xorg-xserver and gtk+3 do_configure fail in poky-pyro

[Jussi Kukkonen]

On 5 July 2017 at 17:10, Joseph Ngigi  wrote:
> | checking for GDK_DEP... no
> | configure: error: Package requirements (pango pangocairo gdk-pixbuf-2.0
>= 2.30.0 cairo >= 1.14.0 cairo-gobject >= 1.14.0 gio-unix-2.0 >= 2.49.4
fontconfig x11 xext xi xrandr xcursor xfixes xcomposite xdamage
wayland-client >= 1.9.91 wayland-protocols >= 1.7 xkbcommon >= 0.2.0
wayland-cursor >= 1.9.91 wayland-egl   cairo-xlib cairo epoxy >= 1.0) were
not met:
> |
> | No package 'wayland-egl' found

This could be a bug in gtk+3 recipe when using something else than mesa:
The wayland packageconfig depends on "virtual/mesa" when it maybe needs
"virtual-egl" instead -- what it's really looking for wayland-egl.pc (which
is normally provided by mesa but I guess on your system it's something
else).

As an aside I have to admit the definitions of our various
virtual-whatevers are not clear to me at all... Is this something we could
reasonably document better ?


> | checking for GLAMOR... yes
> | checking for GBM... no
> | configure: error: Glamor for Xorg requires gbm >= 10.2.0

Here the glamor packageconfig seems to be missing a dependency on something
that provides libgbm (again we probably don't normally notice this because
the provider is mesa). My guess is that "virtual/libgl" _usually_ provides
libgbm, so adding that to glamor packageconfig dependencies might be a fix.


HTH,
 Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] RPi app built with SDK won't load

[Paul D. DeRocco]

I incorporated all the relevant symbols from 
environment-setup-cortexa7hf-neon-vfpv4-poky-linux-gnueabi. I defined the 
compilation command as ${CC} ${CFLAGS} and the linker command as ${LD} 
${LDFLAGS}. Other Eclipse settings added -O3 -Wall -c to the compile, and -s to 
the link.

When I did the build, the compile succeeded, but the link complained about 
"-Wl,-O1" as an unrecognized option. I first tried eliminating the "-Wl," 
prefixes, but that gave me a "cannot find entry symbol _start" error. I put the 
"-Wl," prefixes back, but changed the link command from 
arm-poky-linux-gnueabi-ld to arm-poky-linux-gnueabi-gcc, and it linked okay, 
but gave me the same runtime error I've been struggling with.

However, Lukasz put his finger on the problem when he wrote

> From: Lukasz Tekieli [mailto:tekieli.luk...@gmail.com] 
> 
> it seems that if linker is called without -mfloat-abi=hard 
> then the ld is set to /lib/ld-linux.so.3 instead of 
> /lib/ld-linux-armhf.so.3 which is the correct one.

It turns out the correct way to run the linker is $CC $CFLAGS $LDFLAGS, not $LD 
$LDFLAGS.

The reason this escaped me for all this time is that I was using 
arm-poky-linux-gnueabi-objdump -x on the executable, and grepping for NEEDED to 
find out what shared libraries were needed. The actual loader isn't listed in 
this way. Using the -s option showed that the .interp section contained the 
string /lib/ld-linux.so.3. Now it correctly shows /lib/ld-linux-armhf.so.3.

Thanks to all who looked into this for me.

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto