Re: [yocto] Building on target

2014-03-14 Thread Gary Thomas 
On 2014-03-14 08:49, Rick Bianchi wrote:
> If I have time today I will try to reproduce your results. If not, I will get 
> to it first thing next week and post my result.

One thing I forgot to point out is I used the identical kernel+modules for
both setups.  I would be interested to see if that makes any difference for
you.  I can't fully test it as my board doesn't have a Linaro kernel.

So there are four combinations - I only tried the first two:
  Yocto kernel + Yocto rootfs
  Yocto kernel + Linaro rootfs
  Linaro kernel + Yocto rootfs
  Linaro kernel + Linaro rootfs

> On Fri, Mar 14, 2014 at 7:38 AM, Gary Thomas  > wrote:
> 
> On 2014-03-12 13:11, Rick Bianchi wrote:
> > usbip from /usr/src/kernel/drivers/staging/usbip
> 
> I finally managed to make this comparison.  I did this by taking my 
> Poky/Yocto
> built system for a i.MX6 system (ARM Cortex-A9) and replaced the rootfs 
> with
> one for the Gumstix Overo (linaro).  The results were nothing like yours, 
> so
> it's a bit confusing.
> 
> I actually built an entire Linux kernel - not just the one directory you 
> mentioned.
> 
> Poky/Yocto - 37 minutes
> Linaro - 48 minutes
> 
> There is some flex in these numbers as they were on different [brand] SD 
> cards, etc,
> but I sure did not see the "5 minutes for Linaro vs 24 hours on Yocto" 
> that you reported.
> 
> Perhaps the only thing I did differently was I added the SDK tools to my 
> Yocto system
> using these meta-packages instead of the list you used.
>   packagegroup-core-sdk packagegroup-core-standalone-sdk-target
> 
> You might try that to see if it makes any difference.
> 
> n.b. part of what took me so long to get these results is I was trying to 
> run this test
> on something closer to your Overo board.  I have an older OMAP DM3730 
> board here that I
> tried to do these same steps, but it was unstable and I could not get the 
> Linaro based
> file system to work at all.  Very strange.  In any case, I think the 
> comparison I did get
> with the i.MX6 is valid.
> 
> > On Wed, Mar 12, 2014 at 11:44 AM, Gary Thomas    >> wrote:
> >
> > On 2014-03-12 10:09, Rick Bianchi wrote:
> > > I completely agree with regards to the comparison, but I have 
> compiled the same exact source on the same target (arm) and it only took 5 
> minutes when running the Linaro image.
> > >
> > > To clarify, the only difference is the build, one is Linaro (took 
> 5 minutes to compile source on the target) and the other Yocto (took almost 
> 24 hours to compile source on the target).
> >
> > Sorry, I missed that this was on the same hardware.
> >
> > What are you building?  I'm going to try and duplicate this here
> > on hardware I have that's quite similar to your Gumstix board.
> >
> > >
> > > Is there something that I am missing?
> > >
> > >
> > > On Wed, Mar 12, 2014 at 8:28 AM, Gary Thomas    >  
>  > >
> > > On 2014-03-12 09:15, Rick Bianchi wrote:
> > > >
> > > > I have the gumstix-console-image with the added packages 
> below. When I compile on the target is take a very long time for it to 
> complete, over 24 hours. I have compiled the same
> > > > code on the same target, but running Linaro image, and it 
> only takes a few minutes. Is there another recipe that I need to add to the 
> build to speed up compiling?
> > >
> > > Doubtful.  The reason your build on the target takes so long 
> is merely
> > > one of horsepower - that little ARM processor just doesn't 
> have it, especially
> > > if you are comparing it to a typical desktop environment.
> > >
> > > > EXTRA_IMAGE_FEATURES += "dev-pkgs"
> > > > IMAGE_INSTALL_append =" autoconf"
> > > > IMAGE_INSTALL_append =" autofs"
> > > > IMAGE_INSTALL_append =" automake"
> > > > IMAGE_INSTALL_append =" ccache”
> > > > IMAGE_INSTALL_append =" chkconfig"
> > > > IMAGE_INSTALL_append =" dbus-glib"
> > > > IMAGE_INSTALL_append =" gcc"
> > > > IMAGE_INSTALL_append =" glib-2.0"
> > > > IMAGE_INSTALL_append =" glib-networking"
> > > > IMAGE_INSTALL_append =" glibmm"
> > > > IMAGE_INSTALL_append =" packagegroup-core-buildessential"
> > > > IMAGE_INSTALL_append =" pciutils"
> > > > IMAGE_INSTALL_append =" pkgconfig”
> > > > IMAGE_INSTALL_append =" python-scons"
> > >

[yocto] [ANNOUNCEMENT] 1.6_M3 released.

2014-03-14 Thread Flanagan, Elizabeth 
The artifacts for the 3rd milestone release of the upcoming Yocto
Project 1.6 release are now available at:

http://downloads.yoctoproject.org/releases/yocto/milestones/1.6_M3/

Features include:

- 41 package updates
- Packaging and rootfs re-factor and conversion to python
- WIC extension for EFI
- Documentation fixes and additions
- Additional packages added support for ptest (total 38 packages now)
- Additional packages added support for systemd (total 26 packages now)

poky 54562006c1327c5b99daa4cc05a3ba7e38412da1
oecore 9a98b8bfe13b94d89a9e39cca821f26fdeaeffc3
meta-qt3 4772424ab69908d4e3b9d6d4717ca889468e6acd
bitbake c39b99792547b642570ea5152070e7396e812390
eclipse-poky-juno 26bfc407781aa185f244a47ba63120343cee4a37
eclipse-poky-kepler f4d8e9243f9355424a01e2d72fd1abbf68d3bb7c
meta-fsl-arm 40385ba8b3060adb3a535c6e5f08199b69f47754
meta-fsl-ppc 290a669e5480792836d4f7769ba2ef6f49799323
meta-intel a2e40547fd6e2e7874e1587956c4490904ce552a
meta-minnow 32e4d6f17917027c3babe1ab738480de9691024d

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

Re: [yocto] Building a metapackage

2014-03-14 Thread David Welch 
Thanks for your quick reponses, that works.


On Fri, Mar 14, 2014 at 4:45 PM, Gary Thomas  wrote:

> On 2014-03-14 10:34, David Welch wrote:
> > Hi,
> >
> > Is it possible to build a meta packages whose sole purpose is to bring
> in dependencies?
> >
> > Suppose I have package-1.deb, package-2.deb and package-3.deb.  I would
> like add a .bb file to build a metapackage for those three packages.  I
> have tried the following but it
> > didn't work:
> >
> > SUMMARY = "Package"
> > DESCRIPTION = ""
> > LICENSE = "CLOSED"
> > DEPENDS = " \
> > package-1 package-2 package-3 \
> > "
> > inherit meta
> >
> > My use case is a series of voices by different manufactures which need
> to be installed on a per-manufacturer basis.  So all the voices from
> manufacture1 would need to be installed
> > on one machine and all the voices from manufacturer2 need to go on
> another machine.  There are about 50-100 voice packages per manufacturer.
>
> I think packagegroups (previously known as tasks) are what you are looking
> for.
>
> --
> 
> Gary Thomas |  Consulting for the
> MLB Associates  |Embedded world
> 
> --
> ___
> 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] Building a metapackage

2014-03-14 Thread Gary Thomas 
On 2014-03-14 10:34, David Welch wrote:
> Hi,
> 
> Is it possible to build a meta packages whose sole purpose is to bring in 
> dependencies?
> 
> Suppose I have package-1.deb, package-2.deb and package-3.deb.  I would like 
> add a .bb file to build a metapackage for those three packages.  I have tried 
> the following but it
> didn't work:
> 
> SUMMARY = "Package"
> DESCRIPTION = ""
> LICENSE = "CLOSED"
> DEPENDS = " \
> package-1 package-2 package-3 \
> "
> inherit meta
> 
> My use case is a series of voices by different manufactures which need to be 
> installed on a per-manufacturer basis.  So all the voices from manufacture1 
> would need to be installed
> on one machine and all the voices from manufacturer2 need to go on another 
> machine.  There are about 50-100 voice packages per manufacturer.

I think packagegroups (previously known as tasks) are what you are looking for.

-- 

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] Building a metapackage

2014-03-14 Thread Burton, Ross 
On 14 March 2014 16:34, David Welch  wrote:
> Is it possible to build a meta packages whose sole purpose is to bring in
> dependencies?

You've just described a package group - have a look at anything called
packagegroup-*.bb in oe-core, and packagegroup.bbclass.

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

[yocto] Building a metapackage

2014-03-14 Thread David Welch 
Hi,

Is it possible to build a meta packages whose sole purpose is to bring in
dependencies?

Suppose I have package-1.deb, package-2.deb and package-3.deb.  I would
like add a .bb file to build a metapackage for those three packages.  I
have tried the following but it didn't work:

SUMMARY = "Package"
DESCRIPTION = ""
LICENSE = "CLOSED"
DEPENDS = " \
package-1 package-2 package-3 \
"
inherit meta

My use case is a series of voices by different manufactures which need to
be installed on a per-manufacturer basis.  So all the voices from
manufacture1 would need to be installed on one machine and all the voices
from manufacturer2 need to go on another machine.  There are about 50-100
voice packages per manufacturer.

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

Re: [yocto] Issue installing External Kernel Module with same name

2014-03-14 Thread Khem Raj 
On Thu, Mar 13, 2014 at 11:00 PM, Ankur Patel  wrote:
> Now the problem is, as kernel also builds the wifi driver modules based on
> the same .config file used by external driver module.


Disable the option in the component where you dont
want it from. In this case kernel
-Khem
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project Technical Team Meeting

2014-03-14 Thread Jolley, Stephen K 
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN="Jolley, Stephen K":MAILTO:stephen.k.jol...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='achaudha@
 mvista.com':MAILTO:achau...@mvista.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Anders Da
 rander':MAILTO:and...@chargestorm.se
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Arce Moren
 o, Abraham":MAILTO:abraham.arce.mor...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Ashfield, 
 Bruce (Wind River)":MAILTO:bruce.ashfi...@windriver.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Barros Pen
 a, Belen":MAILTO:belen.barros.p...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Burton, Ro
 ss":MAILTO:ross.bur...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Butler, Pa
 ul A (Wind River)":MAILTO:paul.but...@windriver.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Chisanovic
 i, IonutX":MAILTO:ionutx.chisanov...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Chris Kam
 inski':MAILTO:chris.kamin...@tobias.tv
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Damian, Al
 exandru":MAILTO:alexandru.dam...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Daniel Ca
 uchy':MAILTO:dcau...@mvista.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="DeVries, A
 lex (Wind River)":MAILTO:alex.devr...@windriver.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Dmytriyenk
 o, Denys":MAILTO:de...@ti.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Erway, Tra
 cey M":MAILTO:tracey.m.er...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Flanagan, 
 Elizabeth":MAILTO:elizabeth.flana...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Gavaz, Ion
 ut A":MAILTO:ionut.a.ga...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Georgescu,
  Alexandru C":MAILTO:alexandru.c.george...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Hart, Darr
 en":MAILTO:darren.h...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Harvey, Mi
 chael":MAILTO:michael.har...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Hatle, Mar
 k G (Wind River)":MAILTO:mark.ha...@windriver.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Hudson, S
 ean'":MAILTO:sean_hud...@mentor.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Iorga, Cri
 stian":MAILTO:cristian.io...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Jeremy Pu
 hlman':MAILTO:jpuhl...@gmail.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Kamble, Ni
 tin A":MAILTO:nitin.a.kam...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Kridner, J
 ason":MAILTO:j...@ti.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Letnes, Th
 addeus C":MAILTO:thaddeus.c.let...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Liu, Song":
 MAILTO:song@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Long, Step
 hen J (Wind River)":MAILTO:steve.l...@windriver.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Long, Yan
 ren'":MAILTO:yl...@wpi.edu
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="'Maupin, C
 hase'":MAILTO:chase.mau...@ti.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Moeller, T
 horsten":MAILTO:thorsten.moel...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Moses, Fre
 d":MAILTO:fred.mo...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Mueller, R
 obert":MAILTO:robert.muel...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Olivia Sal
 isbury:MAILTO:olivia.salisb...@tobias.tv
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Ong, Boon 
 Leong":MAILTO:boon.leong@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Osier-mixo
 n, Jeffrey":MAILTO:jeffrey.osier-mi...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Palalau, A
 lexandruX":MAILTO:alexandrux.pala...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Patel, Key
 ur R":MAILTO:keyur.r.pa...@intel.com
ATTENDEE;ROLE

[yocto] Issue installing External Kernel Module with same name

2014-03-14 Thread Ankur Patel 
Hello Friends,

I am using Poky version of Yocto for building images for imx28 evk.

I have to included the receipe which builds the TI Comapt Wifi Driver as 
External Module and adds itself to the core-minimal-image.

Below line is used under the layer.conf file to add TI WiFi Driver to rootfs:

MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "ti-compat-wireless-wl18xx"

Now the problem is, as kernel also builds the wifi driver modules based on the 
same .config file used by external driver module. This generates two different 
rpm images for same wifi driver at tmp/deploy/rpm/imx28evk directory as below:

test@test-VirtualBox:~/mx28_repo/mx28_build/tmp/deploy/rpm/imx28evk$ ls 
kernel-module-wl18xx-*
kernel-module-wl18xx-3.10.32+git-r0.imx28evk.rpm
kernel-module-wl18xx-r8.a8.08-0b.imx28evk.rpm

The Final rootfs contains the .ko files from 
"kernel-module-wl18xx-3.10.32+git-r0.imx28evk.rpm
" RPM instead of "kernel-module-wl18xx-r8.a8.08-0b.imx28evk.rpm".

Is there any way to modify the linux receipe not create RPMs for specific 
modules? Or Install specific kernel module with version as r8.a8.08-0b for 
wl18xx?

Please feel free to share if you need further information.

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

Re: [yocto] What is the best practice for customizing libraries included in yocto distribution?

2014-03-14 Thread Gary Thomas 
On 2014-03-14 09:45, Federico Vitali wrote:
> It worked! Thank you so much! Now I have to go out, I have only to understand
> a couple of things...
> 
> 1. how to make bitbake understand that I've only changed one or more file, 
> now I have
> to do bitbake -c clean gst-plugins-base && bitbake gst-plugins-base

If you've only changed a file or two, try this instead:
  $ bitbake gst-plugins-base -C compile

If you made a change that requires rerunning the 'configure' step,
just use that instead of 'compile'.

> 2. how to debug via Eclipse.
> 
> Thank you again!
> 
> 
> Federico
> 
> 
> 
> 2014-03-14 11:18 GMT+01:00 Nicolas Dechesne  >:
> 
> Frederico,
> 
> On Fri, Mar 14, 2014 at 11:09 AM, Federico Vitali  > wrote:
> > Thank you Nicholas and Gary! I'm quite experienced in linux embedded
> > developement, but I'm new to yocto / openembedded.
> > Nicolas, can you please explain me how to use my sources separate from 
> OE
> > build dir tree and still using oe built system?
> > Do I have to edit the sources directly in builddir/tmp/work/etcetera or 
> can
> > I keep it separate?
> 
> Please have a look at
> 
> 
> http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-classes-externalsrc
> 
> http://www.yoctoproject.org/docs/1.5.1/dev-manual/dev-manual.html#building-software-from-an-external-source
> 
> let us know if you have additional questions
> 
> 

-- 

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] What is the best practice for customizing libraries included in yocto distribution?

2014-03-14 Thread Federico Vitali 
It worked! Thank you so much! Now I have to go out, I have only to
understand
a couple of things...

1. how to make bitbake understand that I've only changed one or more file,
now I have
to do bitbake -c clean gst-plugins-base && bitbake gst-plugins-base

2. how to debug via Eclipse.

Thank you again!


Federico



2014-03-14 11:18 GMT+01:00 Nicolas Dechesne :

> Frederico,
>
> On Fri, Mar 14, 2014 at 11:09 AM, Federico Vitali 
> wrote:
> > Thank you Nicholas and Gary! I'm quite experienced in linux embedded
> > developement, but I'm new to yocto / openembedded.
> > Nicolas, can you please explain me how to use my sources separate from OE
> > build dir tree and still using oe built system?
> > Do I have to edit the sources directly in builddir/tmp/work/etcetera or
> can
> > I keep it separate?
>
> Please have a look at
>
>
> http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-classes-externalsrc
>
> http://www.yoctoproject.org/docs/1.5.1/dev-manual/dev-manual.html#building-software-from-an-external-source
>
> let us know if you have additional questions
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Building on target

2014-03-14 Thread Rick Bianchi 
If I have time today I will try to reproduce your results. If not, I will
get to it first thing next week and post my result.

Thanks,
Rick


On Fri, Mar 14, 2014 at 7:38 AM, Gary Thomas  wrote:

> On 2014-03-12 13:11, Rick Bianchi wrote:
> > usbip from /usr/src/kernel/drivers/staging/usbip
>
> I finally managed to make this comparison.  I did this by taking my
> Poky/Yocto
> built system for a i.MX6 system (ARM Cortex-A9) and replaced the rootfs
> with
> one for the Gumstix Overo (linaro).  The results were nothing like yours,
> so
> it's a bit confusing.
>
> I actually built an entire Linux kernel - not just the one directory you
> mentioned.
>
> Poky/Yocto - 37 minutes
> Linaro - 48 minutes
>
> There is some flex in these numbers as they were on different [brand] SD
> cards, etc,
> but I sure did not see the "5 minutes for Linaro vs 24 hours on Yocto"
> that you reported.
>
> Perhaps the only thing I did differently was I added the SDK tools to my
> Yocto system
> using these meta-packages instead of the list you used.
>   packagegroup-core-sdk packagegroup-core-standalone-sdk-target
>
> You might try that to see if it makes any difference.
>
> n.b. part of what took me so long to get these results is I was trying to
> run this test
> on something closer to your Overo board.  I have an older OMAP DM3730
> board here that I
> tried to do these same steps, but it was unstable and I could not get the
> Linaro based
> file system to work at all.  Very strange.  In any case, I think the
> comparison I did get
> with the i.MX6 is valid.
>
> > On Wed, Mar 12, 2014 at 11:44 AM, Gary Thomas  g...@mlbassoc.com>> wrote:
> >
> > On 2014-03-12 10:09, Rick Bianchi wrote:
> > > I completely agree with regards to the comparison, but I have
> compiled the same exact source on the same target (arm) and it only took 5
> minutes when running the Linaro image.
> > >
> > > To clarify, the only difference is the build, one is Linaro (took
> 5 minutes to compile source on the target) and the other Yocto (took almost
> 24 hours to compile source on the target).
> >
> > Sorry, I missed that this was on the same hardware.
> >
> > What are you building?  I'm going to try and duplicate this here
> > on hardware I have that's quite similar to your Gumstix board.
> >
> > >
> > > Is there something that I am missing?
> > >
> > >
> > > On Wed, Mar 12, 2014 at 8:28 AM, Gary Thomas 
> >  g...@mlbassoc.com> >>
> wrote:
> > >
> > > On 2014-03-12 09:15, Rick Bianchi wrote:
> > > >
> > > > I have the gumstix-console-image with the added packages
> below. When I compile on the target is take a very long time for it to
> complete, over 24 hours. I have compiled the same
> > > > code on the same target, but running Linaro image, and it
> only takes a few minutes. Is there another recipe that I need to add to the
> build to speed up compiling?
> > >
> > > Doubtful.  The reason your build on the target takes so long
> is merely
> > > one of horsepower - that little ARM processor just doesn't
> have it, especially
> > > if you are comparing it to a typical desktop environment.
> > >
> > > > EXTRA_IMAGE_FEATURES += "dev-pkgs"
> > > > IMAGE_INSTALL_append =" autoconf"
> > > > IMAGE_INSTALL_append =" autofs"
> > > > IMAGE_INSTALL_append =" automake"
> > > > IMAGE_INSTALL_append =" ccache"
> > > > IMAGE_INSTALL_append =" chkconfig"
> > > > IMAGE_INSTALL_append =" dbus-glib"
> > > > IMAGE_INSTALL_append =" gcc"
> > > > IMAGE_INSTALL_append =" glib-2.0"
> > > > IMAGE_INSTALL_append =" glib-networking"
> > > > IMAGE_INSTALL_append =" glibmm"
> > > > IMAGE_INSTALL_append =" packagegroup-core-buildessential"
> > > > IMAGE_INSTALL_append =" pciutils"
> > > > IMAGE_INSTALL_append =" pkgconfig"
> > > > IMAGE_INSTALL_append =" python-scons"
> > > > IMAGE_INSTALL_append =" systemd-compat-units"
> > > > IMAGE_INSTALL_append =" sysfsutils"
> > > > IMAGE_INSTALL_append =" tcp-wrappers"
> > > > IMAGE_INSTALL_append =" usbutils"
> > > > IMAGE_INSTALL_append =" util-macros"
>
> --
> 
> Gary Thomas |  Consulting for the
> MLB Associates  |Embedded world
> 
> --
> ___
> 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] Building on target

2014-03-14 Thread Gary Thomas 
On 2014-03-12 13:11, Rick Bianchi wrote:
> usbip from /usr/src/kernel/drivers/staging/usbip

I finally managed to make this comparison.  I did this by taking my Poky/Yocto
built system for a i.MX6 system (ARM Cortex-A9) and replaced the rootfs with
one for the Gumstix Overo (linaro).  The results were nothing like yours, so
it's a bit confusing.

I actually built an entire Linux kernel - not just the one directory you 
mentioned.

Poky/Yocto - 37 minutes
Linaro - 48 minutes

There is some flex in these numbers as they were on different [brand] SD cards, 
etc,
but I sure did not see the "5 minutes for Linaro vs 24 hours on Yocto" that you 
reported.

Perhaps the only thing I did differently was I added the SDK tools to my Yocto 
system
using these meta-packages instead of the list you used.
  packagegroup-core-sdk packagegroup-core-standalone-sdk-target

You might try that to see if it makes any difference.

n.b. part of what took me so long to get these results is I was trying to run 
this test
on something closer to your Overo board.  I have an older OMAP DM3730 board 
here that I
tried to do these same steps, but it was unstable and I could not get the 
Linaro based
file system to work at all.  Very strange.  In any case, I think the comparison 
I did get
with the i.MX6 is valid.

> On Wed, Mar 12, 2014 at 11:44 AM, Gary Thomas  > wrote:
> 
> On 2014-03-12 10:09, Rick Bianchi wrote:
> > I completely agree with regards to the comparison, but I have compiled 
> the same exact source on the same target (arm) and it only took 5 minutes 
> when running the Linaro image.
> >
> > To clarify, the only difference is the build, one is Linaro (took 5 
> minutes to compile source on the target) and the other Yocto (took almost 24 
> hours to compile source on the target).
> 
> Sorry, I missed that this was on the same hardware.
> 
> What are you building?  I'm going to try and duplicate this here
> on hardware I have that's quite similar to your Gumstix board.
> 
> >
> > Is there something that I am missing?
> >
> >
> > On Wed, Mar 12, 2014 at 8:28 AM, Gary Thomas    >> wrote:
> >
> > On 2014-03-12 09:15, Rick Bianchi wrote:
> > >
> > > I have the gumstix-console-image with the added packages below. 
> When I compile on the target is take a very long time for it to complete, 
> over 24 hours. I have compiled the same
> > > code on the same target, but running Linaro image, and it only 
> takes a few minutes. Is there another recipe that I need to add to the build 
> to speed up compiling?
> >
> > Doubtful.  The reason your build on the target takes so long is 
> merely
> > one of horsepower - that little ARM processor just doesn't have it, 
> especially
> > if you are comparing it to a typical desktop environment.
> >
> > > EXTRA_IMAGE_FEATURES += "dev-pkgs"
> > > IMAGE_INSTALL_append =" autoconf"
> > > IMAGE_INSTALL_append =" autofs"
> > > IMAGE_INSTALL_append =" automake"
> > > IMAGE_INSTALL_append =" ccache”
> > > IMAGE_INSTALL_append =" chkconfig"
> > > IMAGE_INSTALL_append =" dbus-glib"
> > > IMAGE_INSTALL_append =" gcc"
> > > IMAGE_INSTALL_append =" glib-2.0"
> > > IMAGE_INSTALL_append =" glib-networking"
> > > IMAGE_INSTALL_append =" glibmm"
> > > IMAGE_INSTALL_append =" packagegroup-core-buildessential"
> > > IMAGE_INSTALL_append =" pciutils"
> > > IMAGE_INSTALL_append =" pkgconfig”
> > > IMAGE_INSTALL_append =" python-scons"
> > > IMAGE_INSTALL_append =" systemd-compat-units”
> > > IMAGE_INSTALL_append =" sysfsutils"
> > > IMAGE_INSTALL_append =" tcp-wrappers"
> > > IMAGE_INSTALL_append =" usbutils"
> > > IMAGE_INSTALL_append =" util-macros"

-- 

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] What is the best practice for customizing libraries included in yocto distribution?

2014-03-14 Thread Federico Vitali 
Thank you Nicolas. Sorry, but I'm new to this extremely powerful building
system, I'm a little confused. Now I'll read the sections you suggest!
Thank you again!

Federico
Il giorno 14/mar/2014 11:18, "Nicolas Dechesne" 
ha scritto:

> Frederico,
>
> On Fri, Mar 14, 2014 at 11:09 AM, Federico Vitali 
> wrote:
> > Thank you Nicholas and Gary! I'm quite experienced in linux embedded
> > developement, but I'm new to yocto / openembedded.
> > Nicolas, can you please explain me how to use my sources separate from OE
> > build dir tree and still using oe built system?
> > Do I have to edit the sources directly in builddir/tmp/work/etcetera or
> can
> > I keep it separate?
>
> Please have a look at
>
>
> http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-classes-externalsrc
>
> http://www.yoctoproject.org/docs/1.5.1/dev-manual/dev-manual.html#building-software-from-an-external-source
>
> let us know if you have additional questions
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] OpenEmbedded Developers meeting after ELC May 2-3

2014-03-14 Thread Philip Balister 
Please read:

http://openembedded.org/wiki/OEDAM

We'd like to get a good idea of the number of people attending. If you
are waiting for approvals to travel, you could add yourself as tentative
so we have some idea of total attendance for planning.

If you are having trouble adding yourself on the wiki, send the info to
me and I can add it for you.

Thanks,

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

Re: [yocto] What is the best practice for customizing libraries included in yocto distribution?

2014-03-14 Thread Nicolas Dechesne 
Frederico,

On Fri, Mar 14, 2014 at 11:09 AM, Federico Vitali  wrote:
> Thank you Nicholas and Gary! I'm quite experienced in linux embedded
> developement, but I'm new to yocto / openembedded.
> Nicolas, can you please explain me how to use my sources separate from OE
> build dir tree and still using oe built system?
> Do I have to edit the sources directly in builddir/tmp/work/etcetera or can
> I keep it separate?

Please have a look at

http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-classes-externalsrc
http://www.yoctoproject.org/docs/1.5.1/dev-manual/dev-manual.html#building-software-from-an-external-source

let us know if you have additional questions
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] What is the best practice for customizing libraries included in yocto distribution?

2014-03-14 Thread Federico Vitali 
Thank you Nicholas and Gary! I'm quite experienced in linux embedded
developement, but I'm new to yocto / openembedded.
Nicolas, can you please explain me how to use my sources separate from OE
build dir tree and still using oe built system?
Do I have to edit the sources directly in builddir/tmp/work/etcetera or can
I keep it separate?




2014-03-14 10:24 GMT+01:00 Nicolas Dechesne :

> On Fri, Mar 14, 2014 at 10:10 AM, Gary Thomas  wrote:
> >>   CCLD   libgsttag-0.10.la 
> >> libtool: link: warning: library
> `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/
> libgstbase-0.10.la ' was moved.
> >> libtool: link: warning: library
> `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/
> libgstreamer-0.10.la ' was moved.
> >> libtool: link: warning: library
> `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/
> libgobject-2.0.la ' was moved.
> >> libtool: link: warning: library
> `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/
> libgmodule-2.0.la ' was moved.
> >> libtool: link: warning: library
> `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/
> libgthread-2.0.la ' was moved.
> >> libtool: link: warning: library
> `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/
> libglib-2.0.la ' was moved.
> >> libtool: link: warning: library
> `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/libxml2.la<
> http://libxml2.la>' was moved.
> >> sed: can't read /usr/lib/libgstreamer-0.10.la <
> http://libgstreamer-0.10.la>: No such file or directory
> >> libtool: link: `=/usr/lib/libgstreamer-0.10.la <
> http://libgstreamer-0.10.la>' is not a valid libtool archive
> >> make[4]: *** [libgsttag-0.10.la ] Errore 1
> >>
> >> The library configured for cross compilation. I'm starting from the
> sources patched as in yocto.
> >>
> >> Any help appreciated!
> >
> > Why not do these changes/development using your bitbake/Yocto
> > build environment.  I've found that using quilt makes this quite
> > easy to do and helps manage the changes, patches, etc.  It will
> > also avoid the problem you are having which seems to stem from
> > trying to build outside the original environment.
>
> yeah. i would recommend that too. I find the externalsrc class quite
> handy for such things. E.g. you can keep your git tree separate during
> development, *but* still rely on OE to build, which I think gives you
> the best of both world...
>
> of course for your own applications, using the SDK makes sense.
>
> nicolas
> --
> ___
> 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] What is the best practice for customizing libraries included in yocto distribution?

2014-03-14 Thread Nicolas Dechesne 
On Fri, Mar 14, 2014 at 10:10 AM, Gary Thomas  wrote:
>>   CCLD   libgsttag-0.10.la 
>> libtool: link: warning: library 
>> `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/libgstbase-0.10.la
>>  ' was moved.
>> libtool: link: warning: library 
>> `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/libgstreamer-0.10.la
>>  ' was moved.
>> libtool: link: warning: library 
>> `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/libgobject-2.0.la
>>  ' was moved.
>> libtool: link: warning: library 
>> `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/libgmodule-2.0.la
>>  ' was moved.
>> libtool: link: warning: library 
>> `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/libgthread-2.0.la
>>  ' was moved.
>> libtool: link: warning: library 
>> `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/libglib-2.0.la
>>  ' was moved.
>> libtool: link: warning: library 
>> `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/libxml2.la 
>> ' was moved.
>> sed: can't read /usr/lib/libgstreamer-0.10.la : 
>> No such file or directory
>> libtool: link: `=/usr/lib/libgstreamer-0.10.la 
>> ' is not a valid libtool archive
>> make[4]: *** [libgsttag-0.10.la ] Errore 1
>>
>> The library configured for cross compilation. I'm starting from the sources 
>> patched as in yocto.
>>
>> Any help appreciated!
>
> Why not do these changes/development using your bitbake/Yocto
> build environment.  I've found that using quilt makes this quite
> easy to do and helps manage the changes, patches, etc.  It will
> also avoid the problem you are having which seems to stem from
> trying to build outside the original environment.

yeah. i would recommend that too. I find the externalsrc class quite
handy for such things. E.g. you can keep your git tree separate during
development, *but* still rely on OE to build, which I think gives you
the best of both world...

of course for your own applications, using the SDK makes sense.

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

Re: [yocto] What is the best practice for customizing libraries included in yocto distribution?

2014-03-14 Thread Gary Thomas 
On 2014-03-14 03:04, Federico Vitali wrote:
> Thank you Nicolas.
> I try to explain better, sorry, yesterday I wrote the email in a hurry.
> 
> I'm working to build an OS based on sato, but I have to modify the code
> of some libraries included in the distribution. When I wrote "customize"
> I meant modify source code.
> 
> I answer to your questions:
> 
> 
> can you be a bit more specific? not sure i understand completely what
> you want to do. also how are you getting your distribution? 
> it's
> prebuilt and you only have the image or you build it yourself from
> recipes? 
> 
> 
> I'm basing my distribution on sato-sdk. I've built it from source. I've built 
> and
> installed a cross toolchain and root filesystem to use for building. I'm 
> developing applications
> using the cross toolchain, adt tools and Eclipse. It is all set up properly.
> 
> 
> 
> telling us more about the trouble might be useful. also telling how
> you build the toolchain and sysrootfs.
> 
> 
> I have to modify some source code of some gstreamer plugins to support
> some custom functionalities. During the developement I would like to
> work outside bitbake to develop / compile / debug on the target. I know
> that when I've finished I can simply add my patch to a bb append file of
> my own, and when the developement will be finished I will certainly do.
> 
> 
> 
> 
> well, that would definitely be the more natural way of customizing
> existing recipes. that's what most people would do in their own
> layers, generally with .bbappend recipes. it's probably even easier to
> do that building your own toolchain/SDK to some extends.. why don't
> you like this option?
> 
> 
> 
> I certainly use this option when I customize existing recipes! My problem
> is in developement phase.
>  
> 
> This is the specific problem I get when I try to build gst-plugins-base:
> 
> ake[4]: ingresso nella directory 
> "/home/vitalife/sources/gst-plugins-base-0.10.36/gst-libs/gst/tag"
>   CC libgsttag_0.10_la-gstvorbistag.lo
>   CC libgsttag_0.10_la-gstid3tag.lo
>   CC libgsttag_0.10_la-gstxmptag.lo
> gstxmptag.c: In function 'xmp_tag_type_get_name':
> gstxmptag.c:178:1: warning: control reaches end of non-void function 
> [-Wreturn-type]
>  }
>  ^
>   CC libgsttag_0.10_la-gstexiftag.lo
>   CC libgsttag_0.10_la-lang.lo
>   CC libgsttag_0.10_la-licenses.lo
>   CC libgsttag_0.10_la-tags.lo
>   CC libgsttag_0.10_la-gsttagdemux.lo
>   CC libgsttag_0.10_la-gsttagmux.lo
>   CC libgsttag_0.10_la-gsttageditingprivate.lo
>   CC libgsttag_0.10_la-id3v2.lo
>   CC libgsttag_0.10_la-id3v2frames.lo
>   CC libgsttag_0.10_la-xmpwriter.lo
>   CCLD   libgsttag-0.10.la 
> libtool: link: warning: library 
> `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/libgstbase-0.10.la
>  ' was moved.
> libtool: link: warning: library 
> `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/libgstreamer-0.10.la
>  ' was moved.
> libtool: link: warning: library 
> `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/libgobject-2.0.la
>  ' was moved.
> libtool: link: warning: library 
> `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/libgmodule-2.0.la
>  ' was moved.
> libtool: link: warning: library 
> `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/libgthread-2.0.la
>  ' was moved.
> libtool: link: warning: library 
> `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/libglib-2.0.la 
> ' was moved.
> libtool: link: warning: library 
> `/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/libxml2.la 
> ' was moved.
> sed: can't read /usr/lib/libgstreamer-0.10.la : 
> No such file or directory
> libtool: link: `=/usr/lib/libgstreamer-0.10.la ' 
> is not a valid libtool archive
> make[4]: *** [libgsttag-0.10.la ] Errore 1
> 
> The library configured for cross compilation. I'm starting from the sources 
> patched as in yocto. 
> 
> Any help appreciated!

Why not do these changes/development using your bitbake/Yocto
build environment.  I've found that using quilt makes this quite
easy to do and helps manage the changes, patches, etc.  It will
also avoid the problem you are having which seems to stem from
trying to build outside the original environment.

-- 

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] What is the best practice for customizing libraries included in yocto distribution?

2014-03-14 Thread Federico Vitali 
Thank you Nicolas.
I try to explain better, sorry, yesterday I wrote the email in a hurry.

I'm working to build an OS based on sato, but I have to modify the code
of some libraries included in the distribution. When I wrote "customize"
I meant modify source code.

I answer to your questions:

>
> can you be a bit more specific? not sure i understand completely what
> you want to do. also how are you getting your distribution?
> it's
> prebuilt and you only have the image or you build it yourself from
> recipes?
>

I'm basing my distribution on sato-sdk. I've built it from source. I've
built and
installed a cross toolchain and root filesystem to use for building. I'm
developing applications
using the cross toolchain, adt tools and Eclipse. It is all set up properly.


>
> telling us more about the trouble might be useful. also telling how
> you build the toolchain and sysrootfs.
>

I have to modify some source code of some gstreamer plugins to support
some custom functionalities. During the developement I would like to
work outside bitbake to develop / compile / debug on the target. I know
that when I've finished I can simply add my patch to a bb append file of
my own, and when the developement will be finished I will certainly do.



>
> well, that would definitely be the more natural way of customizing
> existing recipes. that's what most people would do in their own
> layers, generally with .bbappend recipes. it's probably even easier to
> do that building your own toolchain/SDK to some extends.. why don't
> you like this option?
>


I certainly use this option when I customize existing recipes! My problem
is in developement phase.


This is the specific problem I get when I try to build gst-plugins-base:

ake[4]: ingresso nella directory
"/home/vitalife/sources/gst-plugins-base-0.10.36/gst-libs/gst/tag"
  CC libgsttag_0.10_la-gstvorbistag.lo
  CC libgsttag_0.10_la-gstid3tag.lo
  CC libgsttag_0.10_la-gstxmptag.lo
gstxmptag.c: In function 'xmp_tag_type_get_name':
gstxmptag.c:178:1: warning: control reaches end of non-void function
[-Wreturn-type]
 }
 ^
  CC libgsttag_0.10_la-gstexiftag.lo
  CC libgsttag_0.10_la-lang.lo
  CC libgsttag_0.10_la-licenses.lo
  CC libgsttag_0.10_la-tags.lo
  CC libgsttag_0.10_la-gsttagdemux.lo
  CC libgsttag_0.10_la-gsttagmux.lo
  CC libgsttag_0.10_la-gsttageditingprivate.lo
  CC libgsttag_0.10_la-id3v2.lo
  CC libgsttag_0.10_la-id3v2frames.lo
  CC libgsttag_0.10_la-xmpwriter.lo
  CCLD   libgsttag-0.10.la
libtool: link: warning: library
`/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/
libgstbase-0.10.la' was moved.
libtool: link: warning: library
`/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/
libgstreamer-0.10.la' was moved.
libtool: link: warning: library
`/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/
libgobject-2.0.la' was moved.
libtool: link: warning: library
`/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/
libgmodule-2.0.la' was moved.
libtool: link: warning: library
`/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/
libgthread-2.0.la' was moved.
libtool: link: warning: library
`/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/
libglib-2.0.la' was moved.
libtool: link: warning: library
`/opt/poky/1.5.1/sysroots/armv6-vfp-poky-linux-gnueabi/usr/lib/libxml2.la'
was moved.
sed: can't read /usr/lib/libgstreamer-0.10.la: No such file or directory
libtool: link: `=/usr/lib/libgstreamer-0.10.la' is not a valid libtool
archive
make[4]: *** [libgsttag-0.10.la] Errore 1

The library configured for cross compilation. I'm starting from the sources
patched as in yocto.

Any help appreciated!
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] What is the best practice for customizing libraries included in yocto distribution?

2014-03-14 Thread Nicolas Dechesne 
Hi,

On Thu, Mar 13, 2014 at 4:52 PM, Federico Vitali  wrote:
> Hi everyone,
>
> what should I do to customize and crosscompile a library already distributed
> with yocto?
>

can you be a bit more specific? not sure i understand completely what
you want to do. also how are you getting your distribution? it's
prebuilt and you only have the image or you build it yourself from
recipes?

>
> I see 2 possibilities:
>
> 1. Build and install a toolchain and sysrootfs on local host and untar the
> original library,
>apply yocto distributed patches and then cross compile ==> I'm having
> trouble here

telling us more about the trouble might be useful. also telling how
you build the toolchain and sysrootfs.

>
> 2. Use the yocto build environment itself, but I don't like this option.

well, that would definitely be the more natural way of customizing
existing recipes. that's what most people would do in their own
layers, generally with .bbappend recipes. it's probably even easier to
do that building your own toolchain/SDK to some extends.. why don't
you like this option?

>
> Does anyone have already customized a library?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto