[oe] Issues with .list files

Phil Blundell philb at gnu.org
Sat Feb 6 11:31:18 UTC 2010


On Thu, 2010-02-04 at 19:24 -0800, Michael Morrell wrote:
> If I understand the algorithm in package_do_shlibs correctly, each package creates a .list file which is a list of all the shared libraries provided by that package.  It also generates a list of all the libraries that it needs and looks for those in .list files created by other packages so it can create a runtime dependency against that package.
> 
> The way it looks for .list files is to simply scan all *.list files in the directory.  This has two problems that I can see.
> 
> First, it is inefficient.  It should only have to look through .list files creates by packages created by bb files which were DEPENDed on by this bb file.

That's an interesting point.  I think this probably is true, although it
would lead to some issues with packages that currently have incomplete
DEPENDS (or which rely on the historically-transitive behaviour of
DEPENDS for correct operation); there are probably quite a lot of these.
If you're going to make this change then I think you would also need to
change the current "couldn't find shlib provider for..." warning into a
fatal error.

Do you have any feel for how much time would actually be saved by
eliminating the unnecessary scan of other .list files?

> Second, when a bitbake run is done with lots of parallelism, it is possible that it tries to open a nonexistent .list file (it was there when it did the os.listdir call, but that package later removed it before it recreates it), causing a crash here.  We are seeing such crashes reasonably often.

This one is definitely just a bug (and, I think, unrelated to the first
issue).  Any time you create or modify a file in a live part of staging,
it needs to be done atomically and it sounds like package.bbclass is
currently failing to do that.  Feel free to make a patch, or I can look
at this instead if you want.

p.






More information about the Openembedded-devel mailing list