From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Juro Bystricky <juro.bystricky@intel.com>,
openembedded-core@lists.openembedded.org
Cc: jurobystricky@hotmail.com
Subject: Re: [PATCH] libc6: improve reproducibility
Date: Sat, 13 Jan 2018 10:11:13 +0000 [thread overview]
Message-ID: <1515838273.29722.133.camel@linuxfoundation.org> (raw)
In-Reply-To: <1515791062-54281-1-git-send-email-juro.bystricky@intel.com>
On Fri, 2018-01-12 at 13:04 -0800, Juro Bystricky wrote:
> Building various libraries (libc6, libc6-pic, libc6-staticdev, libc6-
> dbg, ...)
> can be non-deterministic because they may be built with two different
> versions
> of intl/plural.c. in two otherwise identical builds. We may or may
> not re-generate
> the file plural.c from the file plural.y, based on bison being
> installed or not
> and based on mtimes of those two files, as the Makefile contains:
>
> plural.c: plural.y
> $(BISON) $(BISONFLAGS) $@ $^
>
> If the above rule does not fire, we use a "fallback" plural.c,
> otherwise
> we use plural.c re-generated from plural.y.
> The fix is to always require bison to be installed and
> unconditionally
> re-generate plural.c. (This is achieved by touching plural.y).
>
> [YOCTO #12291]
>
> Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
> ---
> meta/recipes-core/glibc/glibc_2.26.bb | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Hi Juro,
Can you put a comment alongside the touch in the recipe as we're not
going to know why we're doing this in a few years time...
Cheers,
Richard
> diff --git a/meta/recipes-core/glibc/glibc_2.26.bb b/meta/recipes-
> core/glibc/glibc_2.26.bb
> index 04d9773..4d9b23f 100644
> --- a/meta/recipes-core/glibc/glibc_2.26.bb
> +++ b/meta/recipes-core/glibc/glibc_2.26.bb
> @@ -5,7 +5,7 @@ LIC_FILES_CHKSUM = "file://LICENSES;md5=e9a558e243b36
> d3209f380deb394b213 \
> file://posix/rxspencer/COPYRIGHT;md5=dc5485bb394a13b2332ec1c78
> 5f5d83a \
> file://COPYING.LIB;md5=4fbd65380cdd255951079008b364516c"
>
> -DEPENDS += "gperf-native"
> +DEPENDS += "gperf-native bison-native"
>
> SRCREV ?= "77f921dac17c5fa99bd9e926d926c327982895f7"
>
> @@ -103,6 +103,7 @@ do_configure () {
> # version check and doesn't really help with anything
> (cd ${S} && gnu-configize) || die "failure in running gnu-
> configize"
> find ${S} -name "configure" | xargs touch
> + find ${S}/intl -name "plural.y" | xargs touch
> CPPFLAGS="" oe_runconf
> }
>
next prev parent reply other threads:[~2018-01-13 10:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-12 21:04 [PATCH] libc6: improve reproducibility Juro Bystricky
2018-01-13 10:11 ` Richard Purdie [this message]
2018-01-13 14:09 ` Bystricky, Juro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1515838273.29722.133.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=juro.bystricky@intel.com \
--cc=jurobystricky@hotmail.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox