On Sat, 2023-11-11 at 05:03 -1000, Steve Sakoman wrote:
> We are seeing reproducibility issues where gcc-cross sometimes defaults
> to gnu11 and other times to gnu17.
>
> Specify std=gnu17 rather than leave this to chance.
>
> Signed-off-by: Steve Sakoman <st...@sakoman.com>
> Signed-off-by: Khem Raj <raj.k...@gmail.com>
> ---
> meta/recipes-support/lz4/lz4_1.9.2.bb | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-support/lz4/lz4_1.9.2.bb
> b/meta/recipes-support/lz4/lz4_1.9.2.bb
> index c2e24b518c..8cf71fdc04 100644
> --- a/meta/recipes-support/lz4/lz4_1.9.2.bb
> +++ b/meta/recipes-support/lz4/lz4_1.9.2.bb
> @@ -23,6 +23,7 @@ S = "${WORKDIR}/git"
> # Fixed in r118, which is larger than the current version.
> CVE_CHECK_WHITELIST += "CVE-2014-4715"
>
> +CFLAGS_append = " -std=gnu17"
> EXTRA_OEMAKE = "PREFIX=${prefix} CC='${CC}' CFLAGS='${CFLAGS}' DESTDIR=${D}
> LIBDIR=${libdir} INCLUDEDIR=${includedir} BUILD_STATIC=no"
>
> do_install() {
I've looked into this a lot more and I'm now of the opinion this is
totally wrong and definitely should not merge.
An example failure is:
http://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20231109-ch73ktqp/packages/diff-html/
First, it is worth noting the huge size difference. It appears debug
line information is being missed out. The difference in cflags is a
false lead, it is because crti.S is compiled with c17 and the producer
string is being mis-compared, the data is missing on one side.
So what we're looking for really is a cflags issue where -g is going
missing.
I did check older failures which look similar:
http://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20231105-_xpb575y/packages/diff-html/
Since we're looking for cflags issues:
https://github.com/lz4/lz4/commit/7d8d1075e696d585238e6aa6a4f43dc759da250e
looks interesting and leads to:
https://savannah.gnu.org/bugs/?func=detailitem&item_id=59230
If the makefile had intermittently picked up CFLAGS from the
environment, the output would be identical to the previous cflags patch
in the series, which would cross link the hash equivalence
inputs/outputs and could generally confuse things.
The real question is which autobuilder worker is compiling without the
-g option and is it a make bug? Perhaps it doesn't matter and we just
need to force the input and output hashes to change to stop the errors
once the previous patch is applied.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#190468):
https://lists.openembedded.org/g/openembedded-core/message/190468
Mute This Topic: https://lists.openembedded.org/mt/102526884/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
