Bitbake producing wrong library when running with less threads

[bernardo]

Hi,

I'm building a Yocto Linux recipe: lxc (Linux Containers) using sdk v1.7 on a Dell system with 24 cores and 32 GB of RAM.

When I run the poky script with options -j 12 -t 12, then bitbake produces a good liblxc.so library. Instead, if I run the poky script with -j 8 -t 8, then bitbake produces a bad library.

The difference between the good and the bad library is that the good library hits the seccomp patch to check the systemcall whitelist and rejects not-allowed system calls. The bad library does't hit it and simply allows all system calls to run. The library have different sizes but there is no other noticeable difference other than the described behaviour.

We still haven't figured out what the problem is. Has anyone seen something like this?.

Thanks.

B.

[madisox]

That sort of difference usually indicates that there's a missing dependency in the recipe -- some packages will automatically configure themselves differently based on the presence or absence of other packages/libraries, so you could different result in different builds (especially if you vary the number of threads).

A quick look at the commit log for the lxc recipe in its git repository turns up: http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/recipes-containers/lxc/lxc_1.0.... which looks like it might be relevant to your problem.

[gusarambula]

As Madisox mentioned it would be good to review the dependencies.

The number of threads should not affect the outcome of baking if all dependencies are explicitly set on the corresponding recipes but if configurations are affected by the presence or absence of other packages bitbake won’t consider this when ordering the task list.