an ipk package depending on its corresponding -dev

an ipk package depending on its corresponding -dev

[Luca Bolognini]

A strange thing happended to me last time I created libgles-omap3 ipk packages.I had justed patched /usr/bin/cputype (a file contained in one of the SRC_URIs) and libgles-omap3.inc to add some INSANE_SKIPs , then I gave the commands:MACHINE=beagleboard bitbake -v -c clean libgles-omap3MACHINE=beagleboard bitbake -v libgles-omap3
At least, it happened that I had the dependency:libgles_omap3 -> libgles_omap3_dev
It's quite strange and it's the first time I see a package depending on its corresponding -dev.Obviously this dependency is false, there can't be any dependency between these two packages.The same action, with MACHINE=c6a816x-evm (in a different development machine) doesn't lead to this behaviour.However I don't think that MACHINE=beagleboard is involved, probably I corrupted something in the 1st development machine, I don't know.Have you any idea how to remove this ugly (and useless) dependency? How could it originate?
Thank you, byeLuca

-------------------------Luca Bologninil.bolognini@hotmail.it


 		 	   		  

Re: an ipk package depending on its corresponding -dev

[Gary Thomas]

On 04/17/2011 07:43 AM, Luca Bolognini wrote:
>
> A strange thing happended to me last time I created libgles-omap3 ipk packages.I had justed patched /usr/bin/cputype (a file contained in one of the SRC_URIs) and libgles-omap3.inc to add some INSANE_SKIPs , then I gave the commands:MACHINE=beagleboard bitbake -v -c clean libgles-omap3MACHINE=beagleboard bitbake -v libgles-omap3
> At least, it happened that I had the dependency:libgles_omap3 ->  libgles_omap3_dev
> It's quite strange and it's the first time I see a package depending on its corresponding -dev.Obviously this dependency is false, there can't be any dependency between these two packages.The same action, with MACHINE=c6a816x-evm (in a different development machine) doesn't lead to this behaviour.However I don't think that MACHINE=beagleboard is involved, probably I corrupted something in the 1st development machine, I don't know.Have you any idea how to remove this ugly (and useless) dependency? How could it originate?

I've seen this happen when something in the package depends on a
library named *.so, instead of a more qualified library such as *.so.1
The *.so files are only packaged in the -dev subpackages by default.

An easy workaround (which might not be perfectly correct) is to just
list the .so files in the main package, e.g.
   FILES_${PN} += "/usr/lib/lib*.so"

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: an ipk package depending on its corresponding -dev

[Luca Bolognini]

Thank you, but my libgles-omap3-dev_4.03.00.01-r11.6_armv7a.ipk includes only /usr/include/* files, as written in the recipe: FILES_${PN}-dev = "${includedir}"
Moreover it doesn't happen when MACHINE=c6a816x-evm... however I don't think MACHINE=beagleboard is involved...

-------------------------Luca Bologninil.bolognini@hotmail.it




> Date: Sun, 17 Apr 2011 08:00:51 -0600
> From: gary@mlbassoc.com
> To: openembedded-devel@lists.openembedded.org
> CC: l.bolognini@hotmail.it
> Subject: Re: [oe] an ipk package depending on its corresponding -dev
> 
> On 04/17/2011 07:43 AM, Luca Bolognini wrote:
> >
> > A strange thing happended to me last time I created libgles-omap3 ipk packages.I had justed patched /usr/bin/cputype (a file contained in one of the SRC_URIs) and libgles-omap3.inc to add some INSANE_SKIPs , then I gave the commands:MACHINE=beagleboard bitbake -v -c clean libgles-omap3MACHINE=beagleboard bitbake -v libgles-omap3
> > At least, it happened that I had the dependency:libgles_omap3 ->  libgles_omap3_dev
> > It's quite strange and it's the first time I see a package depending on its corresponding -dev.Obviously this dependency is false, there can't be any dependency between these two packages.The same action, with MACHINE=c6a816x-evm (in a different development machine) doesn't lead to this behaviour.However I don't think that MACHINE=beagleboard is involved, probably I corrupted something in the 1st development machine, I don't know.Have you any idea how to remove this ugly (and useless) dependency? How could it originate?
> 
> I've seen this happen when something in the package depends on a
> library named *.so, instead of a more qualified library such as *.so.1
> The *.so files are only packaged in the -dev subpackages by default.
> 
> An easy workaround (which might not be perfectly correct) is to just
> list the .so files in the main package, e.g.
>    FILES_${PN} += "/usr/lib/lib*.so"
> 
> -- 
> ------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------------------------------------