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
------------------------------------------------------------
_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
