[OE-core] [PATCH] sqlite3: Always build sqlite3-native with zlib

[Jason Wessel]

On 8/6/19 12:55 PM, Alexander Kanavin wrote:
>
>
> On Tue, 6 Aug 2019 at 19:31, Jason Wessel <jason.wessel at windriver.com <mailto:jason.wessel at windriver.com>> wrote:
>
>     The build of sqlite3-native is not fully deterministic.  There is some
>     corner case as shown with the recent pseudo commit where the sqlite3
>     will sometimes link against zlib.  It is possible that in a build with
>     sstate that since the zlib is not listed, that pseudo-native will fail
>     to build because it calls the pkg-config to get the link arguments for
>     sqlite3 and will ultimately try to link against zlib.
>
>
> It would be good to dig a little deeper and get to the root cause of why sqlite *sometimes* does it. The fix provided below seems like fixing the symptom, not the problem.
>
> Alex


Without getting access to the build machine where it failed to perform more in depth forensics it is a bit hard to determine the exact cause.  I performed some local testing using the Fedora 28 and could not replicate the exact circumstance unless I deleted a file in the sysroot.  From what I can tell there are two ways of seeing the problem.

1) Host contamination

% pkg-config sqlite3 --libs --static
-lsqlite3 -lm -ldl -lz -lpthread

This was not the way the sqlite3 was built.  However there is no way to know if this was the circumstance without poking around in the log files and re-running the context of the run.do_compile script in the packages temp directory.

2) Dependency race

This is the one where I deleted a file to simulate the problem, but I couldn't reproduce it.  For this, we'd really need to look at the failed machine's log of the build of sqlite3, which may be long gone from the sstate.  But it should have the pkg-config files laying around.  If it shows that it did build against the zlib, but zlib was not listed dependency it was never going to build because the recipe-sysroot-native is not going to have the required library.

There of course might be other ways to end up with the same result but these are the most likely candidates, each of which is fixed by listing the dependency.   I too would like to know the actual root cause, but without access to the build it is hard to track it down.

Cheers,

Jason

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20190806/23af4b2e/attachment.html>