[yocto] Release Candidate Build for yocto-2.1_M2.rc1_M2.rc1 now available.

2016-01-27 Thread Poky Build User 
-e 
A release candidate build for yocto-2.1_M2.rc1 is now available at:

 
http://autobuilder.yoctoproject.org/pub/releases/yocto-2.1_M2.rc1


Please begin QA on this build as soon as possible.


Build hash information: 
meta-intel : b42a7e91320a75871b30ec851d6ec02711bbad0d 
meta-fsl-arm : c1a4b18f3fcf9258ab1ab5b3bf27fadef29e9827 
meta-minnow : 9c965ef5252e383843d796cd8b50c61b3034b6ae 
meta-qt4 : 80e9ccf584ea215ac0e9706bd1df852bb2bb4ba9 
meta-qt3 : 7d958b928a4a38a186746fabbc0d8169dd8bb3a6 
meta-fsl-ppc : cb8d8ffd03645f58b530cc62e9a943a7bf93476c 
poky : 3d2c0f5902cacf9d8544bf263b51ef0dd1a7218c 


This is an automated message from
The Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder
Email: elizabeth.flana...@intel.com 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Detecting missing build dependencies

2016-01-27 Thread Ulf Magnusson 
Hello,

If a recipe has a missing build dependency that the sysroot just
happens to contain anyway from an earlier build, then the build will
succeed only to fail later when the sysroot no longer has the build
dependency. We want to avoid that, so we're looking for ways to
automatically check for unspecified build dependencies.

The only method I know of at the moment is to remove or rename tmp/ so
that the build uses a fresh sysroot and then trying to rebuild the
recipe. Is there something nicer? I think I remember reading about a
script for testing for missing build dependencies, but I might be
misremembering.

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

Re: [yocto] Detecting missing build dependencies

2016-01-27 Thread Martin Jansa 
On Wed, Jan 27, 2016 at 03:45:30PM +0100, Ulf Magnusson wrote:
> Hello,
> 
> If a recipe has a missing build dependency that the sysroot just
> happens to contain anyway from an earlier build, then the build will
> succeed only to fail later when the sysroot no longer has the build
> dependency. We want to avoid that, so we're looking for ways to
> automatically check for unspecified build dependencies.
> 
> The only method I know of at the moment is to remove or rename tmp/ so
> that the build uses a fresh sysroot and then trying to rebuild the
> recipe. Is there something nicer? I think I remember reading about a
> script for testing for missing build dependencies, but I might be
> misremembering.

See openembedded-core/scripts/test-dependencies.sh but it basically
automates rebuilding recipes after removing TMPDIR, but also it detects
autodetected dependencies.

Regards,

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Detecting missing build dependencies

2016-01-27 Thread Burton, Ross 
On 27 January 2016 at 14:45, Ulf Magnusson  wrote:

> The only method I know of at the moment is to remove or rename tmp/ so
> that the build uses a fresh sysroot and then trying to rebuild the
> recipe. Is there something nicer? I think I remember reading about a
> script for testing for missing build dependencies, but I might be
> misremembering.
>

You're thinking of scripts/test-dependencies.sh.

Personally I just use wipe-sysroot (faster than deleting tmp) and
buildhistory-diff to verify build dependencies.

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

Re: [yocto] Detecting missing build dependencies

2016-01-27 Thread Ulf Magnusson 
On Wed, Jan 27, 2016 at 3:59 PM, Martin Jansa  wrote:
> On 27 January 2016 at 14:45, Ulf Magnusson  wrote:
>> ...
> See openembedded-core/scripts/test-dependencies.sh but it basically
> automates rebuilding recipes after removing TMPDIR, but also it detects
> autodetected dependencies.
>
> Regards,
>
> --
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com

On Wed, Jan 27, 2016 at 4:02 PM, Burton, Ross  wrote:
>
> On 27 January 2016 at 14:45, Ulf Magnusson  wrote:
>> ...
>
> You're thinking of scripts/test-dependencies.sh.
>
> Personally I just use wipe-sysroot (faster than deleting tmp) and
> buildhistory-diff to verify build dependencies.
>
> Ross

Thanks for the tips! I have two questions:

 1) Why does test-dependencies.sh remove TMPDIR instead of just wiping the
sysroots?

 2) Is there any overhead for subsequent builds from wiping the sysroots?
Guessing there shouldn't be, but better check.

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

Re: [yocto] Detecting missing build dependencies

2016-01-27 Thread Burton, Ross 
On 27 January 2016 at 15:29, Ulf Magnusson  wrote:

>  1) Why does test-dependencies.sh remove TMPDIR instead of just wiping the
> sysroots?
>

For the thorough testing that test-dependencies does you could argue that
entirely wiping tmpdir ensures that the builds are done from clean.

 2) Is there any overhead for subsequent builds from wiping the sysroots?
> Guessing there shouldn't be, but better check.
>

Only the overhead of extracting from sstate to repopulate the sysroot.

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

[yocto] [PATCH][yocto-autobuilder] nightly-checkuri.conf: exclude lsof, run against universe

2016-01-27 Thread Ross Burton 
The lsof recipe needs to be excluded from our checkuri tests because the
upstream FTP server refuses to let the autobuilder machines connect to it.

Also run checkuri against universe instead of world to catch more variations on
recipe permuatations.

Signed-off-by: Ross Burton 
---
 buildset-config.controller/nightly-checkuri.conf | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/buildset-config.controller/nightly-checkuri.conf 
b/buildset-config.controller/nightly-checkuri.conf
index 232f62c..b571429 100644
--- a/buildset-config.controller/nightly-checkuri.conf
+++ b/buildset-config.controller/nightly-checkuri.conf
@@ -16,6 +16,7 @@ steps: [{'SetDest':{}},
 {'GetDistroVersion' : {'distro': 'poky'}},
 {'CreateAutoConf': {'machine': 'qemux86', 'SDKMACHINE' : 'x86_64',
 'distro': 'poky',
-'atextprepend': 'SOURCE_MIRROR_FETCH = "1"\n'}},
+'atextprepend': 'SOURCE_MIRROR_FETCH = "1"\n',
+'atextappend': 'do_checkuri_pn-lsof = ""\n'}},
 {'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
-{'BuildImages': {'images': 'world -c checkuri'}}]
+{'BuildImages': {'images': 'universe -c checkuri'}}]
-- 
2.6.4

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

[yocto] do_compile fails in Jethro

2016-01-27 Thread Alexandre Freire da Silva Osorio 
Hi!

The first time I tried to upgrade my build to Jethro I received the following 
error message while do_compiling krb5:

(...)
| 
.build/tmp/sysroots/x86_64-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/5.2.0/ld:
 plugins.so: relocation R_X86_64_PC32 against symbol `krb5int_open_plugin' can 
not be used when making a shared object; recompile with -fPIC
| 
.build/tmp/sysroots/x86_64-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/5.2.0/ld:
 final link failed: Bad value
| collect2: error: ld returned 1 exit status
| make[2]: *** [libkrb5support.so.0.1] Error 1
| make[2]: Leaving directory 
`.build/tmp/work/core2-64-poky-linux/krb5/1.13.2-r0/krb5-1.13.2/src/util/support'
| make[1]: *** [all-recurse] Error 1
| make[1]: Leaving directory 
`.build/tmp/work/core2-64-poky-linux/krb5/1.13.2-r0/krb5-1.13.2/src/util'
| make: *** [all-recurse] Error 1
| ERROR: oe_runmake failed
| ERROR: Function failed: do_compile (log file is located at 
.build/tmp/work/core2-64-poky-linux/krb5/1.13.2-r0/temp/log.do_compile.9043)
ERROR: Task 1764 
(.meta-openembedded/meta-oe/recipes-connectivity/krb5/krb5_1.13.2.bb, 
do_compile) failed with exit code '1'


This error doesn't occur when I was using Fido. Please, could anyone give me a 
help?

Thanks in advance.

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

[yocto] Image size

2016-01-27 Thread Max Sht 
Hi.

Thank you in advance for your support.
I'm using Yocto project Linux for the iMX6 CPU and imx6ulevk board.

I think that I have a problem with image size. I've seen the basic image
for that board and it's size was about 6Mb, but it didn't contain any
graphical library.
I need a basic graphical library, so I added FB library. My image size is
now larger than 350Mb.
Is it normal? Is there a possibility to make the image *much* smaller with
some other graphic library?

I'm very to new to Linux, and hope that you can help me.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Package woes

2016-01-27 Thread Carles Tronchoni 


Enviado desde mi iPhone
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Embedded Linux Conference, YP DevDay, and OEDAM

2016-01-27 Thread Jeff Osier-Mixon 
If you are planning to attend the Embedded Linux Conference in San
Diego this April, I wanted to let you know about the Yocto Project
Developer Day that the team is planning. This will be similar to
previous DevDays, with hands-on training in both introductory and
advanced tracks. The day will happen just after ELC, on April 7 at the
Marriott in downtown San Diego, just across from the ELC venue. We'll
have more details posted later this week.

The project is also a sponsor for the event and we will have a booth.
If you have something cool that you have been working on and would
like to show it off in the booth during the conference, let me know
and we'll see what we can do to make some space for your project.

For those also in the OpenEmbedded community, there will be an OE
developer's meeting and working session on Friday, April 8. This is a
working session for OE members (not an educational session, sorry!)
and space is limited, so if you plan to attend, please let me know so
I can plan space accordingly.

thanks!

-- 
Jeff Osier-Mixon
Open Source Community Architect, Intel Corporation
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH][yocto-autobuilder] nightly-checkuri.conf: exclude lsof, run against universe

2016-01-27 Thread Flanagan, Elizabeth 
On 27 January 2016 at 15:54, Ross Burton  wrote:
> The lsof recipe needs to be excluded from our checkuri tests because the
> upstream FTP server refuses to let the autobuilder machines connect to it.
>
> Also run checkuri against universe instead of world to catch more variations 
> on
> recipe permuatations.
>
> Signed-off-by: Ross Burton 
> ---
>  buildset-config.controller/nightly-checkuri.conf | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/buildset-config.controller/nightly-checkuri.conf 
> b/buildset-config.controller/nightly-checkuri.conf
> index 232f62c..b571429 100644
> --- a/buildset-config.controller/nightly-checkuri.conf
> +++ b/buildset-config.controller/nightly-checkuri.conf
> @@ -16,6 +16,7 @@ steps: [{'SetDest':{}},
>  {'GetDistroVersion' : {'distro': 'poky'}},
>  {'CreateAutoConf': {'machine': 'qemux86', 'SDKMACHINE' : 'x86_64',
>  'distro': 'poky',
> -'atextprepend': 'SOURCE_MIRROR_FETCH = "1"\n'}},
> +'atextprepend': 'SOURCE_MIRROR_FETCH = "1"\n',
> +'atextappend': 'do_checkuri_pn-lsof = ""\n'}},
>  {'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
> -{'BuildImages': {'images': 'world -c checkuri'}}]
> +{'BuildImages': {'images': 'universe -c checkuri'}}]
> --
> 2.6.4
>

Pulled. Expect production later this evening.


-- 
Elizabeth Flanagan
Yocto Project
Build and Release
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Embedded Linux Conference, YP DevDay, and OEDAM

2016-01-27 Thread akuster 


On 01/27/2016 10:15 AM, Jeff Osier-Mixon wrote:
> If you are planning to attend the Embedded Linux Conference in San
> Diego this April, I wanted to let you know about the Yocto Project
> Developer Day that the team is planning. This will be similar to
> previous DevDays, with hands-on training in both introductory and
> advanced tracks. The day will happen just after ELC, on April 7 at the
> Marriott in downtown San Diego, just across from the ELC venue. We'll
> have more details posted later this week.
> 
> The project is also a sponsor for the event and we will have a booth.
> If you have something cool that you have been working on and would
> like to show it off in the booth during the conference, let me know
> and we'll see what we can do to make some space for your project.

I will be bring at least one demo. Not sure if its cool.

> 
> For those also in the OpenEmbedded community, there will be an OE
> developer's meeting and working session on Friday, April 8. This is a
> working session for OE members (not an educational session, sorry!)
> and space is limited, so if you plan to attend, please let me know so
> I can plan space accordingly.

I will be there. I take it there will be a wiki sigh up like before?

- armin
> 
> thanks!
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] About how port yocto to a customized MIPS cpu

2016-01-27 Thread Khem Raj 
On Tue, Jan 26, 2016 at 7:09 PM, 张健  wrote:

> But I have no idea what's inside the .img files, and how to let my fpga
> board to understand the .img files.
>
> So this  is reason why I'm here to ask you guys for some help.
>
> And wish to know if it is possible to port the "yocto" to my own project.
>
>
​image files are generated in several formats. There is option to generate
tarballs. You can always take the tarball and untar it and look what inside
secondly, for your FPGA to understand this, you probably will need tools to
download the binary to memory which is visitible to FPGA if I assume FPGA
is sitting along with a application processor which can then help you to
flash it to relevant memory parts.

if your application processor has a bootloader e.g. uboot which can use SD
cards as boot media then you can use wic tool to generate SD card
images directly from yocto. wic is documented in dev manual so please look
there on how to set it up. Or you can look at some other BSPs like
beaglebone ( angstrom ) or raspberrypi or freescale layer for scripts to
generate the SD card images and model your using those.​
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Image size

2016-01-27 Thread Khem Raj 
On Sat, Jan 23, 2016 at 6:12 AM, Max Sht  wrote:
> Hi.
>
> Thank you in advance for your support.
> I'm using Yocto project Linux for the iMX6 CPU and imx6ulevk board.
>
> I think that I have a problem with image size. I've seen the basic image for
> that board and it's size was about 6Mb, but it didn't contain any graphical
> library.
> I need a basic graphical library, so I added FB library. My image size is
> now larger than 350Mb.
> Is it normal? Is there a possibility to make the image much smaller with
> some other graphic library?
>
> I'm very to new to Linux, and hope that you can help me.

you can look into buildhistory to help you find the dependency chain
in local.conf you need to enable buildhistory generation

then do a build before adding FB lib and after adding libs
then go into buildhistory repo and do
git show

it will show you top commit showing all the changes in packages
and image after you added FB lib

>
> --
> ___
> 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] do_compile fails in Jethro

2016-01-27 Thread Khem Raj 
On Wed, Jan 27, 2016 at 11:11 AM, Alexandre Freire da Silva Osorio
 wrote:
> Hi!
>
> The first time I tried to upgrade my build to Jethro I received the following 
> error message while do_compiling krb5:
>
> (...)
> | 
> .build/tmp/sysroots/x86_64-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/5.2.0/ld:
>  plugins.so: relocation R_X86_64_PC32 against symbol `krb5int_open_plugin' 
> can not be used when making a shared object; recompile with -fPIC
> | 
> .build/tmp/sysroots/x86_64-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/5.2.0/ld:
>  final link failed: Bad value
> | collect2: error: ld returned 1 exit status
> | make[2]: *** [libkrb5support.so.0.1] Error 1
> | make[2]: Leaving directory 
> `.build/tmp/work/core2-64-poky-linux/krb5/1.13.2-r0/krb5-1.13.2/src/util/support'
> | make[1]: *** [all-recurse] Error 1
> | make[1]: Leaving directory 
> `.build/tmp/work/core2-64-poky-linux/krb5/1.13.2-r0/krb5-1.13.2/src/util'
> | make: *** [all-recurse] Error 1
> | ERROR: oe_runmake failed
> | ERROR: Function failed: do_compile (log file is located at 
> .build/tmp/work/core2-64-poky-linux/krb5/1.13.2-r0/temp/log.do_compile.9043)
> ERROR: Task 1764 
> (.meta-openembedded/meta-oe/recipes-connectivity/krb5/krb5_1.13.2.bb, 
> do_compile) failed with exit code '1'
>
>
> This error doesn't occur when I was using Fido. Please, could anyone give me 
> a help?

what happens if you add

CFLAGS += "-fPIC -DPIC" to concerned .bb file.

>
> Thanks in advance.
>
> Regards,
> Alexandre
> --
> ___
> 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] Kernel build gets stuck in a endless loop

2016-01-27 Thread Christian Ege 
Hi,

Thanks to Guiseppe Pagano, there is a solution for this issue. It is
more a hot fix than a real solution but this is maybe for someone else
helpful.

> Hi Crhistian,
> It is not a clean patch, but it works for me.
> 
> File:kernel_imx_3.14/Makefile
> 
> - $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
> + if [[ ! -e include/config/auto.conf ]]; then $(MAKE) -f
> $(srctree)/Makefile silentoldconfig ; fi
> 
> In this way:
> 
> 
> # If .config is newer than include/config/auto.conf, someone tinkered
> # with it and forgot to run make oldconfig.
> # if auto.conf.cmd is missing then we are probably in a cleaned tree so
> # we execute the config step to be sure to catch updated Kconfig files
> include/config/%.conf: $(KCONFIG_CONFIG) include/config/auto.conf.cmd
> if [[ ! -e include/config/auto.conf ]]; then $(MAKE) -f
> $(srctree)/Makefile silentoldconfig ; fi
> #   $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
> else
> # external modules needs include/generated/autoconf.h and
> include/config/auto.conf
> # but do not care if they are up-to-date. Use auto.conf to trigger the test
> PHONY += include/config/auto.conf
> 
> I had a similar problem during Android 5.0 build process, ad this patch
> solves. Hope it will the same for you.
> 
> If it works I'll pass the patch to udooneo Team.
I've added this to my UDOO layer in a slightly modified version:

https://github.com/graugans/meta-udoo/blob/jethro/recipes-kernel/linux/linux-udooboard/0003-avoid-endless-loop.patch

Regards,
Christian

> 
> Bye
> Giuseppe
> 
> 
> 
> 2016-01-03 19:14 GMT+01:00 Christian Ege  >:
> 
> Hi Giuseppe,
> 
> Am 03.01.2016 7:08 nachm. schrieb "Giuseppe Pagano"
> >
> > Did you solved ?
> I did a little investigation but did not finally succeeded.
> > Maybe I have a patch for you.
> >
> This would be awesome.
> 
> Regards,
> Christian
> 
> 
> >
> >
> > Christian Ege k4230r6 at gmail.com  
> > Sun Nov 29 12:24:50 PST 2015
> >
> > Previous message: [yocto] [meta-security][PATCH] nmap: package
> update to 7.0
> > Next message: [yocto] [Recipe reporting system] Upgradable recipe
> name list
> > Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> > 
> >
> > Hi,
> >
> > can anyone give me some advice how to debug an endless loop during
> > kernel and module recipes with my UDOO Neo support layer?
> >
> > https://github.com/graugans/meta-fsl-arm-extra/tree/master-udooneo
> >
> > When I build the kernel for the UDOO Neo kernel or a module with
> bitbake
> > the bitbake process hangs in an endless loop:
> >
> >
> > bitbake -v kernel-module-imx-gpu-viv
> >
> > + cd
> >
> 
> /data/FSL/fsl-community-bsp-master/build/tmp/work/udooneo-poky-linux-gnueabi/kernel-module-imx-gpu-viv/5.0.11.p7.1+fslc+gitAUTOINC+eeeb23c0fb-r0/git
> > + do_make_scripts
> > + unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
> > + make CC=arm-poky-linux-gnueabi-gcc  -mno-thumb-interwork -marm
> > -fuse-ld=bfd LD=arm-poky-linux-gnueabi-ld.bfd
> > AR=arm-poky-linux-gnueabi-ar  -C
> >
> 
> /data/FSL/fsl-community-bsp-master/build/tmp/work-shared/udooneo/kernel-source
> >
> 
> O=/data/FSL/fsl-community-bsp-master/build/tmp/work-shared/udooneo/kernel-build-artifacts
> > scripts
> >
> > make: Entering directory
> >
> 
> '/data/FSL/fsl-community-bsp-master/build/tmp/work-shared/udooneo/kernel-source'
> >
> >   GEN
> >
> 
> /data/FSL/fsl-community-bsp-master/build/tmp/work-shared/udooneo/kernel-build-artifacts/Makefile
> >
> > scripts/kconfig/conf --silentoldconfig Kconfig
> >
> >   GEN
> >
> 
> /data/FSL/fsl-community-bsp-master/build/tmp/work-shared/udooneo/kernel-build-artifacts/Makefile
> >
> > scripts/kconfig/conf --silentoldconfig Kconfig
> >
> >   GEN /data/FSL/fsl-community-bsp-master/build/tmp/work-shared
> >
> > For the kernel I can workaround this by adding the following line
> to the
> > recipe:
> >
> > B = "${S}"
> >
> > But this does not work for kernel module recipes like the
> > "kernel-module-imx-gpu-viv"
> 
> 

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

Re: [yocto] Embedded Linux Conference, YP DevDay, and OEDAM

2016-01-27 Thread Philip Balister 
On 01/27/2016 07:49 PM, akuster wrote:
> 
> 
> On 01/27/2016 10:15 AM, Jeff Osier-Mixon wrote:
>> If you are planning to attend the Embedded Linux Conference in San
>> Diego this April, I wanted to let you know about the Yocto Project
>> Developer Day that the team is planning. This will be similar to
>> previous DevDays, with hands-on training in both introductory and
>> advanced tracks. The day will happen just after ELC, on April 7 at the
>> Marriott in downtown San Diego, just across from the ELC venue. We'll
>> have more details posted later this week.
>>
>> The project is also a sponsor for the event and we will have a booth.
>> If you have something cool that you have been working on and would
>> like to show it off in the booth during the conference, let me know
>> and we'll see what we can do to make some space for your project.
> 
> I will be bring at least one demo. Not sure if its cool.
> 
>>
>> For those also in the OpenEmbedded community, there will be an OE
>> developer's meeting and working session on Friday, April 8. This is a
>> working session for OE members (not an educational session, sorry!)
>> and space is limited, so if you plan to attend, please let me know so
>> I can plan space accordingly.
> 
> I will be there. I take it there will be a wiki sigh up like before?

Yep, I'm on the road, but will copy the last OE developer meeting to
start to page. If you do not have a wiki account go ahead and make on.
Accounts need to be approved by a human now, the spammers were getting
bad again :(

Philip



> 
> - armin
>>
>> thanks!
>>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] extracting SDK for supporting both 32 and 64 bit applications

2016-01-27 Thread Michael Fainstein 
Dear community,

I am using Freescale's SDK 1.8 based on poky 1.6.2.

How can extract SDK that supports building of both 32 and 64 bit applications?

I defined configuration for my board to be 32 bit with 64 bit kernel and 
extracted SDK for application development.
Everything works fine: I can build 32 bit applications and execute them on my 
board and peek at PCI memory that is far above 32 bit memory limit.
I can build and load kernel loadable modules using bitbake.
However, building kernel modules using extracted SDK fails: while there are 64 
bit tools in bitbake environment, there are no 64 bit tools and 64 bit headers 
in extracted SDK environment.
I tried also to define my board as 64 bit with multilibs and added to my image 
32-bit libraries. However, in this configuration the extracted SDK didn't 
contain 32 bit tools and headers. How do I add both 32 and 64 bit tools and 
headers to native SDK?


Thank you,
Michael
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto