On 8/6/19 2:17 PM, Alexander Kanavin wrote:
On Tue, 6 Aug 2019 at 20:52, Jason Wessel <jason.wes...@windriver.com <mailto:jason.wes...@windriver.com>> wrote: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. This is not quite what I meant. I meant looking at the source code of sqlite, and finding out how exactly it is looking for zlib, and where things might go wrong (e.g. host contamination, or other possible causes of non-determinism). There might be a configure switch to control that behavior, or something similar that we can use to achieve deterministic builds.
Sqlite3 doesn't have a an explicit disable. It has the typical autoconf check for a header/library. From configure.ac: AC_CHECK_HEADERS(zlib.h,[ AC_SEARCH_LIBS(deflate,z,[BUILD_CFLAGS="$BUILD_CFLAGS -DSQLITE_HAVE_ZLIB"]) ]) This means it would need to be patched if you want to make it a pkgconfig option, or play games with the configure cache values... I chose zlib as a default dependency because it was the easiest to implement. If we really want to make it not build with zlib or build it conditionally, it is certainly possible. Is that what is needed to get this patch accepted? Jason.
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
