On 8/6/19 1:36 PM, Jason Wessel wrote:
On 8/6/19 12:55 PM, Alexander Kanavin wrote:
On Tue, 6 Aug 2019 at 19:31, Jason Wessel <jason.wes...@windriver.com
<mailto:jason.wes...@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.
Just to follow up to be very specific about how I deleted files, you can see
the identical failure with:
sudo yum install -y zlib-devel
rm -rf tmp
bitbake -c cleansstate sqlite3-native
bitbake sqlite3-native
sudo yum remove -y zlib-devel
bitbake -c cleansstate pseudo-native
bitbake pseudo-native
I seriously doubt this is exactly what is going on on the host builder which
failed. More analysis would be needed as I explained earlier to draw a final
conclusion. Either way sqlite3-native should be configured to build
consistently, which would prevent this kind of contamination.
Cheers,
Jason.
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core