guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ludovic Courtès
Subject: [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
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

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 <address@hidden> 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’.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]