[Top][All Lists]

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

bug#36747: Official MesCC bootstrap binaries differ from my locally buil

From: Bengt Richter
Subject: bug#36747: Official MesCC bootstrap binaries differ from my locally built ones
Date: Thu, 29 Aug 2019 15:28:14 -0700
User-agent: Mutt/1.12.1 (2019-06-15)

On +2019-08-27 11:38:31 +0200, Ludovic Courtès wrote:
> Hi Mark,
> Mark H Weaver <address@hidden> skribis:
> > Ludovic Courtès <address@hidden> writes:
> >
> >> Mark H Weaver <address@hidden> skribis:
> [...]
> >>> commit 82eaac49ac983f28768d6623d802f41cbd7f779b
> >>> Author: Mark H Weaver <address@hidden>
> >>> Date:   Thu Aug 15 16:44:36 2019 -0400
> >>>
> >>>   gnu: bash: Unconditionally configure PGRP_PIPE for *-linux systems.
> >>>   
> >>>   * gnu/packages/patches/bash-linux-pgrp-pipe.patch: New file.
> >>>   * gnu/local.mk (dist_patch_DATA): Add it.
> >>>   * gnu/packages/bash.scm (bash)[source]: Add the patch.
> [...]
> >> OK.  The Bash change means we’re rebuilding from scratch on
> >> architectures, not just x86.  So I’ll probably ungraft my Ghostscript
> >> fix (466ff55c72959ba1499ce3ec69f534b3038eb30b) while we’re at it.
> >
> > Hmm, good point.  Perhaps we should postpone the Bash fix until the next
> > core-updates cycle.  The problem was quite severe in bash-4.4, which
> > builds incorrectly on linux-5.0 or later, but the issue in bash-5.0 is
> > far less likely to cause problems in practice: it will build differently
> > on linux-2.3 or earlier.
> >
> > What do you think?
> Your call: if you think this Bash fix can be delayed without causing
> problems, then please revert it and we’ll apply it on the next cycle.
> That would allow us to merge ‘core-updates’ more quickly for sure!
> Thanks,
> Ludo’.


(Just in case this might be relevant, sorry if not :)

I noticed that the guix-built version of bash is not position-independent,
and also differences in built-for versions, wondered why:

$ type bash which
bash is /home/bokr/.guix-profile/bin/bash
which is /home/bokr/.guix-profile/bin/which

$ which -a bash
$ which -a bash|xargs readlink -f

$ which -a bash|xargs readlink -f|xargs file
    ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked,
    for GNU/Linux 2.6.32, not stripped
    ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked,
    interpreter /lib64/ld-linux-x86-64.so.2, 
    for GNU/Linux 3.2.0, stripped

If you substitute guile for bash in the above, it shows the same differences.

Could something need position-independence only under special circumstances
and silently give up if not repositionable, causing mystery errors?

Also, I am in the foreign (ArchLinux) host environment twilight zone
of mixed /usr vs ~/.guix-profile name searches and wonder if
there are hidden /usr dependencies baked statically into some /gnu/store 
that are causing me problems.

exec is a bash built-in, and I suppose that is usually doesn't matter
if a guile script is launched via

    exec guile ...

but I have a hunch that sometimes it does matter, because editing scripts
to do hash-bang with


has made a locale error ("guile: warning: failed to install locale")
go away and the script execute successfully, vs not executing beyond the error.

Also, what about the shell that runs first, when I log in?
Should I set SHELL=/gnu/... ? And/or reconfigure to get login/systemd
to launch /gnu/.../bash ?

I had hoped a binary install could give me clean separation of
guix pull goodies vs pacman -Syu (ArchLinux's package installer/updater)
stuff, but it seems difficult to control the env name environment that
both guix and non-guix use.

My setup, fwiw:
guix describe:

Generation 11   Aug 25 2019 20:58:43    (current)
  guix a707484
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: a707484d64e7e46f8cb8401c660fbb6eb77ab9c6

uname -a:
Linux PhantoNv4ArchGx 5.2.9-arch1-1-ARCH #1 SMP PREEMPT Fri Aug 16 11:29:43 UTC 
2019 x86_64 GNU/Linux

Well, sorry if these observations are explained in a FAQ.
I note that there is no -pie in the guix version of this:

[15:14 ~/bs]$ which -a gcc|while read line;do { echo -e "$line:   ";$line -v 
--version|& cat -n|egrep -on -e ' -pie ' ; } ;done
32: -pie
34: -pie
[15:14 ~/bs]$

HTH in some way, PMJI if not.
Bengt Richter

reply via email to

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