GNU bug report logs - #31955
[PATCH] gnu: rust: support build with glibc-2.27, update to 1.26.2

Previous Next

Full log

Message #32 received at 31955 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Danny Milosavljevic <dannym <at> scratchpost.org>
Cc: Nikolai Merinov <nikolai.merinov <at> member.fsf.org>, 31955 <at> debbugs.gnu.org,
 Nils Gillmann <ng0 <at> n0.is>,
 Clément Lassieur <clement <at> lassieur.org>
Subject: Re: [bug#31955] [PATCH] gnu: rust: support build with glibc-2.27,
 update to 1.26.2
Date: Sat, 07 Jul 2018 16:53:48 +0200

Hello Danny,

To make progress and allow Rust to be used along with glibc 2.27, what
about incorporating Nicolai’s patch (assuming it’s all fine), and
investigating the reproducibility issues separately?

If this plan sounds good to you, please push Nicolai’s patch.

Danny Milosavljevic <dannym <at> scratchpost.org> skribis:

> in trying to further limit the area where the rust update doesn't build for me, I invoked
>
> $ guix build --rounds=2 -e '(@ (gnu packages rust) rust-1.23)' >RR3 2>&1
> <works fine>
> $ guix build --rounds=2 -e '(@ (gnu packages rust) rust-1.24)' >RR4 2>&1
> <works fine>
> $ guix build --rounds=2 -e '(@ (gnu packages rust) rust-1.25)' >RR5 2>&1
> <reproducibility error>
>
> Furthermore, I've got a locale (?) problem since updating guix which makes the message in
> RR5 say:
>
>   output â of â differs from â from previous round

These format strings in build.cc use curly quotes, which I’ve tried to
avoid in the C++ code base, but this slept through.  Regardless, the
client code in (guix store) is supposed to interpret what the daemon
sends as UTF-8, and then to display it in the current locale encoding
(converting it if necessary.)

Could you try to strace ‘guix build’ to see whether the client receives
a correct string in the first place?

Then we should probably change those curly quotes to straight quotes in
build.cc (curly quotes should be added by the message translations, when
appropriate.)

> │ │ │ -   773: 000000000003bf40  5571 FUNC    LOCAL  DEFAULT   12 _ZN6syntax5visit9walk_expr17h6eaff91d038660deE
> │ │ │ +   773: 000000000003bf40  5572 FUNC    LOCAL  DEFAULT   12 _ZN6syntax5visit9walk_expr17h6eaff91d038660deE

Looks like this particular ‘walk_expr’ method is offset for some reason,
probably causing all the other changes.

Could you diff the two build logs to see if there’s any hint, like the
order in which file names appear on the link command line?

Also, can you make sure the build doesn’t rely on ‘-fprofile-use’ or
similar?

Thanks,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.