Re: an ipk package depending on its corresponding -dev

[Gary Thomas <gary@mlbassoc.com>]

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
------------------------------------------------------------