Re: 08/33: gnu: make: Revert to 4.1 for the Hurd.

Re: 08/33: gnu: make: Revert to 4.1 for the Hurd.

[Ludovic Courtès]

Hello janneke!

I’m commenting as I see messages come by, hope that’s fine.  :-)

guix-commits@gnu.org skribis:

> commit f7804e0f00741a65e7538fe7f3f0cf9844c2165c
> Author: Jan Nieuwenhuizen <janneke@gnu.org>
> AuthorDate: Wed Feb 26 20:22:18 2020 -0500
>
>     gnu: make: Revert to 4.1 for the Hurd.
>     
>     * gnu/packages/base.scm (gnu-make-4.1): New variable.
>     * gnu/packages/commencement.scm (gnu-make-boot0): Use it for the Hurd.

How much effort would it be to patch current Make for the Hurd?  It
would be ideal if we could apply the patch unconditionally and have a
single Make variant.

>  (define gnu-make-boot0
>    (package
>      (inherit gnu-make)
> -    (source (bootstrap-origin (package-source gnu-make)))
> +    (version (if (hurd-system?) "4.1"
> +                 (package-version gnu-make)))
> +    (source (if (hurd-system?)
> +                (bootstrap-origin (package-source gnu-make-4.1))
> +                (bootstrap-origin (package-source gnu-make))))

This won’t work as expected because ‘source’ is no thunked, and thus
(hurd-system?)  is evaluated at the top level, when the module is
loaded.  (IOW, if you do “-s i586-gnu” from GNU/Linux, it’ll go through
the wrong arm of the ‘if’.)

Ludo’.

Re: 08/33: gnu: make: Revert to 4.1 for the Hurd.

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

Hello Ludo,

> I’m commenting as I see messages come by, hope that’s fine.  :-)

Sure, that's great!

> guix-commits@gnu.org skribis:
>
>> commit f7804e0f00741a65e7538fe7f3f0cf9844c2165c
>> Author: Jan Nieuwenhuizen <janneke@gnu.org>
>> AuthorDate: Wed Feb 26 20:22:18 2020 -0500
>>
>>     gnu: make: Revert to 4.1 for the Hurd.
>>     
>>     * gnu/packages/base.scm (gnu-make-4.1): New variable.
>>     * gnu/packages/commencement.scm (gnu-make-boot0): Use it for the Hurd.
>
> How much effort would it be to patch current Make for the Hurd?  It
> would be ideal if we could apply the patch unconditionally and have a
> single Make variant.

I agree, I don't know :-)  v4.3 compiles fine but apart from --help and
--version it hangs when invoked.  I hoped it would be fixed after
applying the clock patches, but those only worked for Python.

We could either try to debug it or try some/all of Debian's glibc
patches.  If it's already fixed by patching glibc, the only effort
involved is suffer some rebuilds.  Unless you have a better idea I'll
have look at patching glibc first.

>>  (define gnu-make-boot0
>>    (package
>>      (inherit gnu-make)
>> -    (source (bootstrap-origin (package-source gnu-make)))
>> +    (version (if (hurd-system?) "4.1"
>> +                 (package-version gnu-make)))
>> +    (source (if (hurd-system?)
>> +                (bootstrap-origin (package-source gnu-make-4.1))
>> +                (bootstrap-origin (package-source gnu-make))))
>
> This won’t work as expected because ‘source’ is no thunked, and thus
> (hurd-system?)  is evaluated at the top level, when the module is
> loaded.  (IOW, if you do “-s i586-gnu” from GNU/Linux, it’ll go through
> the wrong arm of the ‘if’.)

Ah, crap!  It seemed to work natively and with -t i586-pc-gnu ... (-s
won't work anyway, right?)  Hmm.

janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: 05/33: gnu: hurd: Fix hurd-target?.

[Ludovic Courtès]

guix-commits@gnu.org skribis:

> commit cd5f9ba3b1130d8f54b1ef33106f25f29732e007
> Author: Jan Nieuwenhuizen <janneke@gnu.org>
> AuthorDate: Wed Mar 4 11:49:46 2020 -0500
>
>     gnu: hurd: Fix hurd-target?.
>     
>     * gnu/packages/hurd.scm (hurd-target?): Bugfix; the arguments to
>     string-suffix? to test (%current-system) were transposed, always resulting
>     in #f.  Use hurd-triplet?.

Would be nice to squash with the previous one.  :-)

Re: 05/33: gnu: hurd: Fix hurd-target?.

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

>>     gnu: hurd: Fix hurd-target?.
>>     
>>     * gnu/packages/hurd.scm (hurd-target?): Bugfix; the arguments to
>>     string-suffix? to test (%current-system) were transposed, always resulting
>>     in #f.  Use hurd-triplet?.
>
> Would be nice to squash with the previous one.  :-)

The previous/next hurd-system one, I guess..  :) done.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: 11/33: gnu: glibc: Add and update patches for the Hurd.

[Ludovic Courtès]

Hi,

guix-commits@gnu.org skribis:

> commit 32d3fa5309532b8bcf7f7be15ffabfa99c6ecfaf
> Author: Jan Nieuwenhuizen <janneke@gnu.org>
> AuthorDate: Sun Mar 1 16:37:37 2020 +0100
>
>     gnu: glibc: Add and update patches for the Hurd.
>     
>     * gnu/packages/patches/glibc-hurd-magic-pid.patch: Remove unused file.
>     * gnu/packages/patches/glibc-hurd-clock_t_centiseconds.patch: New file.
>     * gnu/packages/patches/glibc-hurd-clock_gettime_monotonic.patch: New file.
>     * gnu/local.mk (dist_patch_DATA): Update them.
>     * gnu/packages/base.scm (glibc): Use two new patches.

[...]

> -            (patches (search-patches "glibc-ldd-x86_64.patch"
> +            (patches `(,@(search-patches "glibc-ldd-x86_64.patch"
                          ^
Superfluous.  :-)

> +                                         "glibc-hurd-clock_t_centiseconds.patch"
> +                                         "glibc-hurd-clock_gettime_monotonic.patch")))))

Nice patches!  Did you submit them upstream?  They are likely to be
applied quite quickly nowadays, so they could make it in glibc 2.32.
(It’s fine to carry them in the meantime, of course.)

Ludo’.

Re: 11/33: gnu: glibc: Add and update patches for the Hurd.

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

>>     * gnu/packages/patches/glibc-hurd-clock_t_centiseconds.patch: New file.
>>     * gnu/packages/patches/glibc-hurd-clock_gettime_monotonic.patch: New file.
>>     * gnu/local.mk (dist_patch_DATA): Update them.
>>     * gnu/packages/base.scm (glibc): Use two new patches.
>
> [...]
>
>> -            (patches (search-patches "glibc-ldd-x86_64.patch"
>> +            (patches `(,@(search-patches "glibc-ldd-x86_64.patch"
>                           ^
> Superfluous.  :-)

Ah yes thanks, removed.  (I had a number of patches that meant to avoid
triggering rebuilds -- this is a leftover.

>> +                                         "glibc-hurd-clock_t_centiseconds.patch"
>> +                                         "glibc-hurd-clock_gettime_monotonic.patch")))))
>
> Nice patches!  Did you submit them upstream?  They are likely to be
> applied quite quickly nowadays, so they could make it in glibc 2.32.
> (It’s fine to carry them in the meantime, of course.)

I "only" forward ported them, and fixed one; only to find the Debian
glibc git archive just yesterday; so very similar ones are in Debian.

It is unclear to me how that works, some are prefixed local-, others
submitted- or unsubmitted-.  I'll have to ask around.

Worse, I just found what I meant to fix before with

    glibc-hurd-clock_gettime_monotonic.patch

namely

    Fatal Python error: Py_Initialize: can't initialize time
    OSError: [Errno 1073741846] Invalid argument

has somehow regressed...bah!  Combining that with our make v4.1/v4.3
problem, I guess I'll need to dive into these Debian patches some more.

Greetings,
janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: 33/33: daemon: Workaround issues for the Hurd.

[Ludovic Courtès]

guix-commits@gnu.org skribis:

> commit c32b64950972a459af7192abd7a8bc9619c013e9
> Author: Manolis Ragkousis <manolis837@gmail.com>
> AuthorDate: Wed Dec 28 02:49:22 2016 +0200
>
>     daemon: Workaround issues for the Hurd.
>     
>     This allows for native builds on the Hurd, doing
>     
>         sudo ./pre-inst-env guix-daemon --disable-chroot --build-users-group=guixbuild &
>         ./pre-inst-env guix build hello
>     
>     * nix/libstore/build.cc (DerivationGoal::startBuilder)[__GNU__]: Allow
>     non-chrooted build.
>     * nix/libutil/util.cc (killUser)[__GNU__]: Avoid wait failure.

[...]

> +++ b/nix/libstore/build.cc
> @@ -1824,7 +1824,7 @@ void DerivationGoal::startBuilder()
>      }
>  
>      if (useChroot) {
> -#if CHROOT_ENABLED
> +#if CHROOT_ENABLED || __GNU__

Can we instead change the #define CHROOT_ENABLED such that
CHROOT_ENABLED is always true when __GNU__?  Also with a comment stating
that GNU supports chroot(2) without being root.

> +++ b/nix/libutil/util.cc
> @@ -872,9 +872,11 @@ void killUser(uid_t uid)
>          _exit(0);
>      });
>  
> +#if !__GNU__
>      int status = pid.wait(true);
>      if (status != 0)
>          throw Error(format("cannot kill processes for uid `%1%': %2%") % uid % statusToString(status));
> +#endif

Do you know what the rationale was?  It looks like it could leave
zombies behind us.

Ludo’.

Re: 33/33: daemon: Workaround issues for the Hurd.

[Jan Nieuwenhuizen]

[-- Attachment #1: Type: text/plain, Size: 1448 bytes --]

Ludovic Courtès writes:

>> -#if CHROOT_ENABLED
>> +#if CHROOT_ENABLED || __GNU__
>
> Can we instead change the #define CHROOT_ENABLED such that
> CHROOT_ENABLED is always true when __GNU__?  Also with a comment stating
> that GNU supports chroot(2) without being root.

I tried a couple of things and then remembered a patch by Manolis that
already does something like this; but nicer.  So, I am now using that
patch and am only keeping this hack in the second patch (both attached)

>> +#if !__GNU__
>>      int status = pid.wait(true);
>>      if (status != 0)
>>          throw Error(format("cannot kill processes for uid `%1%': %2%") % uid % statusToString(status));
>> +#endif
>
> Do you know what the rationale was?  It looks like it could leave
> zombies behind us.

No, maybe Manolis knows?  What I do know is why I used the patch: before
applying this patch I could only build up to binutils-boot0.
binutils-boot0 would always fail like so

    ./pre-inst-env guix build -e '(@@ (gnu packages commencement) binutils-boot0)' --no-offload
    XXX fails: Workaround for nix daemon
phase `compress-documentation' succeeded after 0.4 seconds
error: cannot kill processes for uid `999': Operation not permitted
guix build: error: cannot kill processes for uid `999': failed with exit code 1

I haven't been seeing zombies but I'll watch for them now; don't know
what's going on here?

Greetings,
janneke


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-daemon-Break-CHROOT_ENABLED-into-smaller-macros.patch --]
[-- Type: text/x-patch, Size: 2272 bytes --]

From 0307646b22fc488e6342f5814fdef336dd154be3 Mon Sep 17 00:00:00 2001
From: Manolis Ragkousis <manolis837@gmail.com>
Date: Sun, 7 Aug 2016 17:48:30 +0300
Subject: [PATCH 1/2] daemon: Break CHROOT_ENABLED into smaller macros.

Checking for CLONE_NEWNS is only needed for using tha Linux specific clone(2),
otherwise we can use fork(2).

* nix/libstore/build.cc (CHROOT_ENABLED): Break into CHROOT_ENABLED
and CLONE_ENABLED.
(DerivationGoal::startBuilder): Replace CHROOT_ENABLED with CLONE_ENABLED.
(DerivationGoal::runChild): Only define pivot_root() if SYS_pivot_root is
defined.
---
 nix/libstore/build.cc | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/nix/libstore/build.cc b/nix/libstore/build.cc
index 17e92c68a7..fc81e14cd1 100644
--- a/nix/libstore/build.cc
+++ b/nix/libstore/build.cc
@@ -52,7 +52,12 @@
 #endif
 
 
-#define CHROOT_ENABLED HAVE_CHROOT && HAVE_SYS_MOUNT_H && defined(MS_BIND) && defined(MS_PRIVATE) && defined(CLONE_NEWNS) && defined(SYS_pivot_root)
+#define CHROOT_ENABLED HAVE_CHROOT && HAVE_SYS_MOUNT_H && defined(MS_BIND) && defined(MS_PRIVATE)
+#define CLONE_ENABLED defined(CLONE_NEWNS)
+
+#if defined(SYS_pivot_root)
+#define pivot_root(new_root, put_old) (syscall(SYS_pivot_root, new_root,put_old))
+#endif
 
 #if CHROOT_ENABLED
 #include <sys/socket.h>
@@ -2005,7 +2010,7 @@ void DerivationGoal::startBuilder()
        - The UTS namespace ensures that builders see a hostname of
          localhost rather than the actual hostname.
     */
-#if CHROOT_ENABLED
+#if CLONE_ENABLED
     if (useChroot) {
 	char stack[32 * 1024];
 	int flags = CLONE_NEWPID | CLONE_NEWNS | CLONE_NEWIPC | CLONE_NEWUTS | SIGCHLD;
@@ -2186,10 +2191,8 @@ void DerivationGoal::runChild()
             if (mkdir("real-root", 0) == -1)
                 throw SysError("cannot create real-root directory");
 
-#define pivot_root(new_root, put_old) (syscall(SYS_pivot_root, new_root, put_old))
             if (pivot_root(".", "real-root") == -1)
                 throw SysError(format("cannot pivot old root directory onto '%1%'") % (chrootRootDir + "/real-root"));
-#undef pivot_root
 
             if (chroot(".") == -1)
                 throw SysError(format("cannot change root directory to '%1%'") % chrootRootDir);
-- 
2.24.0


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-daemon-Avoid-killing-issues-for-the-Hurd.patch --]
[-- Type: text/x-patch, Size: 1420 bytes --]

From f7a04d93f8ef43d56809dc7171b8e681982e2b51 Mon Sep 17 00:00:00 2001
From: Manolis Ragkousis <manolis837@gmail.com>
Date: Wed, 28 Dec 2016 02:49:22 +0200
Subject: [PATCH 2/2] daemon: Avoid killing issues for the Hurd.

This allows for native builds on the Hurd, doing

    sudo ./pre-inst-env guix-daemon --disable-chroot --build-users-group=guixbuild &
    ./pre-inst-env guix build hello

XXX This works around

    ./pre-inst-env guix build -e '(@@ (gnu packages commencement) binutils-boot0)' --no-offload
    phase `compress-documentation' succeeded after 0.4 seconds
    error: cannot kill processes for uid `999': Operation not permitted
    guix build: error: cannot kill processes for uid `999': failed with exit code 1

* nix/libutil/util.cc (killUser)[__GNU__]: Avoid wait failure.
---
 nix/libutil/util.cc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/nix/libutil/util.cc b/nix/libutil/util.cc
index fb2dfad1f7..df2cb1eb09 100644
--- a/nix/libutil/util.cc
+++ b/nix/libutil/util.cc
@@ -872,9 +872,11 @@ void killUser(uid_t uid)
         _exit(0);
     });
 
+#if !__GNU__
     int status = pid.wait(true);
     if (status != 0)
         throw Error(format("cannot kill processes for uid `%1%': %2%") % uid % statusToString(status));
+#endif
 
     /* !!! We should really do some check to make sure that there are
        no processes left running under `uid', but there is no portable
-- 
2.24.0


[-- Attachment #4: Type: text/plain, Size: 152 bytes --]


-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: 33/33: daemon: Workaround issues for the Hurd.

[Ludovic Courtès]

Hi!

Jan Nieuwenhuizen <janneke@gnu.org> skribis:

>>> +#if !__GNU__
>>>      int status = pid.wait(true);
>>>      if (status != 0)
>>>          throw Error(format("cannot kill processes for uid `%1%': %2%") % uid % statusToString(status));
>>> +#endif
>>
>> Do you know what the rationale was?  It looks like it could leave
>> zombies behind us.
>
> No, maybe Manolis knows?  What I do know is why I used the patch: before
> applying this patch I could only build up to binutils-boot0.
> binutils-boot0 would always fail like so
>
>     ./pre-inst-env guix build -e '(@@ (gnu packages commencement) binutils-boot0)' --no-offload
>     XXX fails: Workaround for nix daemon
> phase `compress-documentation' succeeded after 0.4 seconds
> error: cannot kill processes for uid `999': Operation not permitted
> guix build: error: cannot kill processes for uid `999': failed with exit code 1

But is the build process actually running as UID 999?  If you pass
‘--disable-chroot’, then I think build users are not used at all, right?

> From 0307646b22fc488e6342f5814fdef336dd154be3 Mon Sep 17 00:00:00 2001
> From: Manolis Ragkousis <manolis837@gmail.com>
> Date: Sun, 7 Aug 2016 17:48:30 +0300
> Subject: [PATCH 1/2] daemon: Break CHROOT_ENABLED into smaller macros.
>
> Checking for CLONE_NEWNS is only needed for using tha Linux specific clone(2),
> otherwise we can use fork(2).
>
> * nix/libstore/build.cc (CHROOT_ENABLED): Break into CHROOT_ENABLED
> and CLONE_ENABLED.
> (DerivationGoal::startBuilder): Replace CHROOT_ENABLED with CLONE_ENABLED.
> (DerivationGoal::runChild): Only define pivot_root() if SYS_pivot_root is
> defined.

[...]

> -#define CHROOT_ENABLED HAVE_CHROOT && HAVE_SYS_MOUNT_H && defined(MS_BIND) && defined(MS_PRIVATE) && defined(CLONE_NEWNS) && defined(SYS_pivot_root)
> +#define CHROOT_ENABLED HAVE_CHROOT && HAVE_SYS_MOUNT_H && defined(MS_BIND) && defined(MS_PRIVATE)
> +#define CLONE_ENABLED defined(CLONE_NEWNS)
> +
> +#if defined(SYS_pivot_root)
> +#define pivot_root(new_root, put_old) (syscall(SYS_pivot_root, new_root,put_old))
> +#endif
>  
>  #if CHROOT_ENABLED
>  #include <sys/socket.h>
> @@ -2005,7 +2010,7 @@ void DerivationGoal::startBuilder()
>         - The UTS namespace ensures that builders see a hostname of
>           localhost rather than the actual hostname.
>      */
> -#if CHROOT_ENABLED
> +#if CLONE_ENABLED
>      if (useChroot) {
>  	char stack[32 * 1024];
>  	int flags = CLONE_NEWPID | CLONE_NEWNS | CLONE_NEWIPC | CLONE_NEWUTS | SIGCHLD;

I’m not sure this is correct.  Perhaps we rather need an “#ifdef
__linux__” around the use of clone(2)?

Other options:

  1. Implement clone(2) with CLONE_NEW* in libc on GNU/Hurd.

  2. Add a “sandbox” abstraction in the daemon, with OS-specific
     implementations of the abstraction (the Nix daemon did that at some
     point, with the goal of supporting proprietary macOS etc.)

     For GNU/Linux, it’d use chroot(2)+clone(NEWNS) etc. as root.

     On GNU/Hurd, it could spawn the process in a sub-Hurd, i.e., with
     its own proc server, root file system server, and without a pfinet
     server running.

Option #2 can be fun to implement and probably easier and less
controversial than Option #1.  However, it does mean adding more code of
the C++ code base, which is sad.

Either way, it’s a bit of work, so this can definitely come later.

Ludo’.

bug#40006: 33/33: daemon: Workaround issues for the Hurd.

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

Hello!

> Jan Nieuwenhuizen <janneke@gnu.org> skribis:
>
>>>> +#if !__GNU__
>>>>      int status = pid.wait(true);
>>>>      if (status != 0)
>>>>          throw Error(format("cannot kill processes for uid `%1%': %2%") % uid % statusToString(status));
>>>> +#endif
>>>
>>> Do you know what the rationale was?  It looks like it could leave
>>> zombies behind us.
>>
>> No, maybe Manolis knows?  What I do know is why I used the patch: before
>> applying this patch I could only build up to binutils-boot0.
>> binutils-boot0 would always fail like so
>>
>>     ./pre-inst-env guix build -e '(@@ (gnu packages commencement) binutils-boot0)' --no-offload
>>     XXX fails: Workaround for nix daemon
>> phase `compress-documentation' succeeded after 0.4 seconds
>> error: cannot kill processes for uid `999': Operation not permitted
>> guix build: error: cannot kill processes for uid `999': failed with exit code 1
>
> But is the build process actually running as UID 999?  If you pass
> ‘--disable-chroot’, then I think build users are not used at all, right?

It seems that they are; I'm running

    sudo ./pre-inst-env guix-daemon --disable-chroot --build-users-group=guixbuild &

and when starting two build processes, I get

    └─sudo(744,root)───guix-daemon(746)─ /

        ─┬─guix-daemon(1484)─┬─guile(1487,guixbuilder01)─ /
         │                   └─guile-2.2(1485)
         └─guix-daemon(1787)─┬─guile(2203,guixbuilder02)─ /

            ──bash(1497)───bash(3964)
            ──make(2512)───gcc(6043)───cc1(6048)

guixbuilder01 is 999, guixbuilder02 is 998 etc.  Does this mean that
root cannot pid.wait() for the builders?  Note that this error does not occur
when building gnu-make-boot0 or diffutils-boot0.

Hmm, after some more playing on the Hurd and our conversation on IRC, I
found that kill -1 simply does not work at the moment.

I copied sysdeps/mach/hurd/kill.c, renamed __kill to debug_kill and
added

--8<---------------cut here---------------start------------->8---
// libc_hidden_def (__kill)
// weak_alias (__kill, kill)

int
main ()
{
  return debug_kill (-1, SIGKILL);
}
--8<---------------cut here---------------end--------------->8---

Running this as a dummy user, it turns out we run

      err = __proc_getpgrppids (proc, - pid, &pids, &npids);

(effectively asking for PIDs in group of PID=1 ??) and returns only one
PID, in my case 5292

--8<---------------cut here---------------start------------->8---
demo@debian:~$ ps -ef -p 5292
    USER   PID  PPID TTY     TIME COMMAND
       -  5292     5   -  0:00.00 /hurd/storeio -Tzero
--8<---------------cut here---------------end--------------->8---

Hmm?  So it seems that kill -1 is currently not supported, or buggy.
I'll look/ask into this some more today.

>> -#define CHROOT_ENABLED HAVE_CHROOT && HAVE_SYS_MOUNT_H && defined(MS_BIND) && defined(MS_PRIVATE) && defined(CLONE_NEWNS) && defined(SYS_pivot_root)
>> +#define CHROOT_ENABLED HAVE_CHROOT && HAVE_SYS_MOUNT_H && defined(MS_BIND) && defined(MS_PRIVATE)
>> +#define CLONE_ENABLED defined(CLONE_NEWNS)
>> +
>> +#if defined(SYS_pivot_root)
>> +#define pivot_root(new_root, put_old) (syscall(SYS_pivot_root, new_root,put_old))
>> +#endif
>>  
>>  #if CHROOT_ENABLED
>>  #include <sys/socket.h>
>> @@ -2005,7 +2010,7 @@ void DerivationGoal::startBuilder()
>>         - The UTS namespace ensures that builders see a hostname of
>>           localhost rather than the actual hostname.
>>      */
>> -#if CHROOT_ENABLED
>> +#if CLONE_ENABLED
>>      if (useChroot) {
>>  	char stack[32 * 1024];
>>  	int flags = CLONE_NEWPID | CLONE_NEWNS | CLONE_NEWIPC | CLONE_NEWUTS | SIGCHLD;
>
> I’m not sure this is correct.  Perhaps we rather need an “#ifdef
> __linux__” around the use of clone(2)?

Okay, let's do that for now.

> Other options:
>
>   1. Implement clone(2) with CLONE_NEW* in libc on GNU/Hurd.
>
>   2. Add a “sandbox” abstraction in the daemon, with OS-specific
>      implementations of the abstraction (the Nix daemon did that at some
>      point, with the goal of supporting proprietary macOS etc.)
>
>      For GNU/Linux, it’d use chroot(2)+clone(NEWNS) etc. as root.
>
>      On GNU/Hurd, it could spawn the process in a sub-Hurd, i.e., with
>      its own proc server, root file system server, and without a pfinet
>      server running.
>
> Option #2 can be fun to implement and probably easier and less
> controversial than Option #1.  However, it does mean adding more code of
> the C++ code base, which is sad.

I'm assuming that 1.is what Manolis wanted to support with his
libhurdutil?  In fact, I forward ported (minimal effort) the patch

    https://gitlab.com/janneke/hurd/-/commit/856e86f2105417363b85b4d7c4d3141f9e81fb56

but haven't tried linking against this yet.  That would be a nice first
step.  2. sounds fun, but it would need more getting familiar with the
Hurd for me :-)  You never know..

> Either way, it’s a bit of work, so this can definitely come later.

Great!

I have just reset wip-hurd again with new attempts for these too; all
somewhat and more experimental patches are at

    https://gitlab.com/janneke/guix/-/tree/wip-hurd-system

Greetings,
janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: 33/33: daemon: Workaround issues for the Hurd.

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

Hello!

> Jan Nieuwenhuizen <janneke@gnu.org> skribis:
>
>>>> +#if !__GNU__
>>>>      int status = pid.wait(true);
>>>>      if (status != 0)
>>>>          throw Error(format("cannot kill processes for uid `%1%': %2%") % uid % statusToString(status));
>>>> +#endif
>>>
>>> Do you know what the rationale was?  It looks like it could leave
>>> zombies behind us.
>>
>> No, maybe Manolis knows?  What I do know is why I used the patch: before
>> applying this patch I could only build up to binutils-boot0.
>> binutils-boot0 would always fail like so
>>
>>     ./pre-inst-env guix build -e '(@@ (gnu packages commencement) binutils-boot0)' --no-offload
>>     XXX fails: Workaround for nix daemon
>> phase `compress-documentation' succeeded after 0.4 seconds
>> error: cannot kill processes for uid `999': Operation not permitted
>> guix build: error: cannot kill processes for uid `999': failed with exit code 1
>
> But is the build process actually running as UID 999?  If you pass
> ‘--disable-chroot’, then I think build users are not used at all, right?

It seems that they are; I'm running

    sudo ./pre-inst-env guix-daemon --disable-chroot --build-users-group=guixbuild &

and when starting two build processes, I get

    └─sudo(744,root)───guix-daemon(746)─ /

        ─┬─guix-daemon(1484)─┬─guile(1487,guixbuilder01)─ /
         │                   └─guile-2.2(1485)
         └─guix-daemon(1787)─┬─guile(2203,guixbuilder02)─ /

            ──bash(1497)───bash(3964)
            ──make(2512)───gcc(6043)───cc1(6048)

guixbuilder01 is 999, guixbuilder02 is 998 etc.  Does this mean that
root cannot pid.wait() for the builders?  Note that this error does not occur
when building gnu-make-boot0 or diffutils-boot0.

Hmm, after some more playing on the Hurd and our conversation on IRC, I
found that kill -1 simply does not work at the moment.

I copied sysdeps/mach/hurd/kill.c, renamed __kill to debug_kill and
added

--8<---------------cut here---------------start------------->8---
// libc_hidden_def (__kill)
// weak_alias (__kill, kill)

int
main ()
{
  return debug_kill (-1, SIGKILL);
}
--8<---------------cut here---------------end--------------->8---

Running this as a dummy user, it turns out we run

      err = __proc_getpgrppids (proc, - pid, &pids, &npids);

(effectively asking for PIDs in group of PID=1 ??) and returns only one
PID, in my case 5292

--8<---------------cut here---------------start------------->8---
demo@debian:~$ ps -ef -p 5292
    USER   PID  PPID TTY     TIME COMMAND
       -  5292     5   -  0:00.00 /hurd/storeio -Tzero
--8<---------------cut here---------------end--------------->8---

Hmm?  So it seems that kill -1 is currently not supported, or buggy.
I'll look/ask into this some more today.

>> -#define CHROOT_ENABLED HAVE_CHROOT && HAVE_SYS_MOUNT_H && defined(MS_BIND) && defined(MS_PRIVATE) && defined(CLONE_NEWNS) && defined(SYS_pivot_root)
>> +#define CHROOT_ENABLED HAVE_CHROOT && HAVE_SYS_MOUNT_H && defined(MS_BIND) && defined(MS_PRIVATE)
>> +#define CLONE_ENABLED defined(CLONE_NEWNS)
>> +
>> +#if defined(SYS_pivot_root)
>> +#define pivot_root(new_root, put_old) (syscall(SYS_pivot_root, new_root,put_old))
>> +#endif
>>  
>>  #if CHROOT_ENABLED
>>  #include <sys/socket.h>
>> @@ -2005,7 +2010,7 @@ void DerivationGoal::startBuilder()
>>         - The UTS namespace ensures that builders see a hostname of
>>           localhost rather than the actual hostname.
>>      */
>> -#if CHROOT_ENABLED
>> +#if CLONE_ENABLED
>>      if (useChroot) {
>>  	char stack[32 * 1024];
>>  	int flags = CLONE_NEWPID | CLONE_NEWNS | CLONE_NEWIPC | CLONE_NEWUTS | SIGCHLD;
>
> I’m not sure this is correct.  Perhaps we rather need an “#ifdef
> __linux__” around the use of clone(2)?

Okay, let's do that for now.

> Other options:
>
>   1. Implement clone(2) with CLONE_NEW* in libc on GNU/Hurd.
>
>   2. Add a “sandbox” abstraction in the daemon, with OS-specific
>      implementations of the abstraction (the Nix daemon did that at some
>      point, with the goal of supporting proprietary macOS etc.)
>
>      For GNU/Linux, it’d use chroot(2)+clone(NEWNS) etc. as root.
>
>      On GNU/Hurd, it could spawn the process in a sub-Hurd, i.e., with
>      its own proc server, root file system server, and without a pfinet
>      server running.
>
> Option #2 can be fun to implement and probably easier and less
> controversial than Option #1.  However, it does mean adding more code of
> the C++ code base, which is sad.

I'm assuming that 1.is what Manolis wanted to support with his
libhurdutil?  In fact, I forward ported (minimal effort) the patch

    https://gitlab.com/janneke/hurd/-/commit/856e86f2105417363b85b4d7c4d3141f9e81fb56

but haven't tried linking against this yet.  That would be a nice first
step.  2. sounds fun, but it would need more getting familiar with the
Hurd for me :-)  You never know..

> Either way, it’s a bit of work, so this can definitely come later.

Great!

I have just reset wip-hurd again with new attempts for these too; all
somewhat and more experimental patches are at

    https://gitlab.com/janneke/guix/-/tree/wip-hurd-system

Greetings,
janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: 33/33: daemon: Workaround issues for the Hurd.

[Ludovic Courtès]

Hi!

Jan Nieuwenhuizen <janneke@gnu.org> skribis:

> Ludovic Courtès writes:
>
> Hello!
>
>> Jan Nieuwenhuizen <janneke@gnu.org> skribis:
>>
>>>>> +#if !__GNU__
>>>>>      int status = pid.wait(true);
>>>>>      if (status != 0)
>>>>>          throw Error(format("cannot kill processes for uid `%1%': %2%") % uid % statusToString(status));
>>>>> +#endif
>>>>
>>>> Do you know what the rationale was?  It looks like it could leave
>>>> zombies behind us.
>>>
>>> No, maybe Manolis knows?  What I do know is why I used the patch: before
>>> applying this patch I could only build up to binutils-boot0.
>>> binutils-boot0 would always fail like so
>>>
>>>     ./pre-inst-env guix build -e '(@@ (gnu packages commencement) binutils-boot0)' --no-offload
>>>     XXX fails: Workaround for nix daemon
>>> phase `compress-documentation' succeeded after 0.4 seconds
>>> error: cannot kill processes for uid `999': Operation not permitted
>>> guix build: error: cannot kill processes for uid `999': failed with exit code 1
>>
>> But is the build process actually running as UID 999?  If you pass
>> ‘--disable-chroot’, then I think build users are not used at all, right?
>
> It seems that they are; I'm running

Oh, OK.

[…]

>> Other options:
>>
>>   1. Implement clone(2) with CLONE_NEW* in libc on GNU/Hurd.
>>
>>   2. Add a “sandbox” abstraction in the daemon, with OS-specific
>>      implementations of the abstraction (the Nix daemon did that at some
>>      point, with the goal of supporting proprietary macOS etc.)
>>
>>      For GNU/Linux, it’d use chroot(2)+clone(NEWNS) etc. as root.
>>
>>      On GNU/Hurd, it could spawn the process in a sub-Hurd, i.e., with
>>      its own proc server, root file system server, and without a pfinet
>>      server running.
>>
>> Option #2 can be fun to implement and probably easier and less
>> controversial than Option #1.  However, it does mean adding more code of
>> the C++ code base, which is sad.
>
> I'm assuming that 1.is what Manolis wanted to support with his
> libhurdutil?  In fact, I forward ported (minimal effort) the patch
>
>     https://gitlab.com/janneke/hurd/-/commit/856e86f2105417363b85b4d7c4d3141f9e81fb56
>
> but haven't tried linking against this yet.  That would be a nice first
> step.  2. sounds fun, but it would need more getting familiar with the
> Hurd for me :-)  You never know..

I suppose the commit you link to could have been used by libc to
implement #1?  Oh, actually, IIRC, Manolis was working on implementing
mount(2) and umount(2) in libc (which would also be needed), and
probably the settrans utilities were part of that effort.

Thanks,
Ludo’.

bug#40006: 33/33: daemon: Workaround issues for the Hurd.

[Ludovic Courtès]

Hi!

Jan Nieuwenhuizen <janneke@gnu.org> skribis:

> Ludovic Courtès writes:
>
> Hello!
>
>> Jan Nieuwenhuizen <janneke@gnu.org> skribis:
>>
>>>>> +#if !__GNU__
>>>>>      int status = pid.wait(true);
>>>>>      if (status != 0)
>>>>>          throw Error(format("cannot kill processes for uid `%1%': %2%") % uid % statusToString(status));
>>>>> +#endif
>>>>
>>>> Do you know what the rationale was?  It looks like it could leave
>>>> zombies behind us.
>>>
>>> No, maybe Manolis knows?  What I do know is why I used the patch: before
>>> applying this patch I could only build up to binutils-boot0.
>>> binutils-boot0 would always fail like so
>>>
>>>     ./pre-inst-env guix build -e '(@@ (gnu packages commencement) binutils-boot0)' --no-offload
>>>     XXX fails: Workaround for nix daemon
>>> phase `compress-documentation' succeeded after 0.4 seconds
>>> error: cannot kill processes for uid `999': Operation not permitted
>>> guix build: error: cannot kill processes for uid `999': failed with exit code 1
>>
>> But is the build process actually running as UID 999?  If you pass
>> ‘--disable-chroot’, then I think build users are not used at all, right?
>
> It seems that they are; I'm running

Oh, OK.

[…]

>> Other options:
>>
>>   1. Implement clone(2) with CLONE_NEW* in libc on GNU/Hurd.
>>
>>   2. Add a “sandbox” abstraction in the daemon, with OS-specific
>>      implementations of the abstraction (the Nix daemon did that at some
>>      point, with the goal of supporting proprietary macOS etc.)
>>
>>      For GNU/Linux, it’d use chroot(2)+clone(NEWNS) etc. as root.
>>
>>      On GNU/Hurd, it could spawn the process in a sub-Hurd, i.e., with
>>      its own proc server, root file system server, and without a pfinet
>>      server running.
>>
>> Option #2 can be fun to implement and probably easier and less
>> controversial than Option #1.  However, it does mean adding more code of
>> the C++ code base, which is sad.
>
> I'm assuming that 1.is what Manolis wanted to support with his
> libhurdutil?  In fact, I forward ported (minimal effort) the patch
>
>     https://gitlab.com/janneke/hurd/-/commit/856e86f2105417363b85b4d7c4d3141f9e81fb56
>
> but haven't tried linking against this yet.  That would be a nice first
> step.  2. sounds fun, but it would need more getting familiar with the
> Hurd for me :-)  You never know..

I suppose the commit you link to could have been used by libc to
implement #1?  Oh, actually, IIRC, Manolis was working on implementing
mount(2) and umount(2) in libc (which would also be needed), and
probably the settrans utilities were part of that effort.

Thanks,
Ludo’.

Re: 15/33: gnu: coreutils: Remove libcap dependency for the Hurd.

[Ludovic Courtès]

guix-commits@gnu.org skribis:

> commit ae159bde64917511d345cd2e1dd1feabe5f73b72
> Author: Jan Nieuwenhuizen <janneke@gnu.org>
> AuthorDate: Sat Mar 7 03:53:38 2020 -0500
>
>     gnu: coreutils: Remove libcap dependency for the Hurd.
>     
>     * gnu/packages/base.scm (coreutils)[inputs]: Remove libcap for the Hurd.
> ---
>  gnu/packages/base.scm | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm
> index 9f1477b..4b347a7 100644
> --- a/gnu/packages/base.scm
> +++ b/gnu/packages/base.scm
> @@ -304,7 +304,9 @@ used to apply commands with arbitrarily long arguments.")
>  
>               ;; Drop the dependency on libcap when cross-compiling since it's
>               ;; not quite cross-compilable.
> -             ,@(if (%current-target-system)
> +             ;; Also, libcap is not available on the Hurd.
> +             ,@(if (or (%current-target-system)
> +                       (hurd-target?))

Perhaps we’d also need something based on ‘supported-platforms’ here.
(Not a blocker, though.)

Ludo’.

Re: 15/33: gnu: coreutils: Remove libcap dependency for the Hurd.

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

> guix-commits@gnu.org skribis:
>>               ;; Drop the dependency on libcap when cross-compiling since it's
>>               ;; not quite cross-compilable.
>> -             ,@(if (%current-target-system)
>> +             ;; Also, libcap is not available on the Hurd.
>> +             ,@(if (or (%current-target-system)
>> +                       (hurd-target?))
>
> Perhaps we’d also need something based on ‘supported-platforms’ here.
> (Not a blocker, though.)

Ah yes, I think that's the right way forward.  Changed it to

commit 7653827b8919ad85d025ba1a701ba38ab7d2e388
Author: Jan Nieuwenhuizen <janneke@gnu.org>
Date:   Sat Mar 7 03:53:38 2020 -0500

    gnu: coreutils: Remove libcap dependency for the Hurd.
    
    * gnu/packages/linux.scm (libcap)[supported-systems]: Remove the Hurd.
    * gnu/packages/base.scm (coreutils)[inputs]: Include libcap only for supported
    systems.  Fixes building on the Hurd.

diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm
index f562a8fef7..03d9e4c0c1 100644
--- a/gnu/packages/base.scm
+++ b/gnu/packages/base.scm
@@ -303,11 +303,13 @@ used to apply commands with arbitrarily long arguments.")
    (inputs `(("acl"  ,acl)                        ; TODO: add SELinux
              ("gmp"  ,gmp)                        ;bignums in 'expr', yay!
 
-             ;; Drop the dependency on libcap when cross-compiling since it's
-             ;; not quite cross-compilable.
-             ,@(if (%current-target-system)
-                   '()
-                   `(("libcap" ,libcap)))))  ;capability support is 'ls', etc.
+             ;; Do not use libcap when cross-compiling since it's not quite
+             ;; cross-compilable; and use it only for supported systems.
+             ,@(if (and (not (%current-target-system))
+                        (not (member (%current-system)
+                                     (package-supported-systems libcap))))
+             `(("libcap" ,libcap))  ;capability support is 'ls', etc.
+             '())))
    (native-inputs
     ;; Perl is needed to run tests in native builds, and to run the bundled
     ;; copy of help2man.  However, don't pass it when cross-compiling since
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index e1959b905c..6bbe132476 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -2068,6 +2068,7 @@ configuration (iptunnel, ipmaddr).")
                                                    (assoc-ref %outputs "out"))
                                     "RAISE_SETFCAP=no")))
     (native-inputs `(("perl" ,perl)))
+    (supported-systems (delete "i586-gnu" %supported-systems))
     (home-page "https://sites.google.com/site/fullycapable/")
     (synopsis "Library for working with POSIX capabilities")
     (description

I am planning a hard reset of wip-hurd when `hello' builds natively
again (and cross builds), hopefully later today.

janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: 15/33: gnu: coreutils: Remove libcap dependency for the Hurd.

[Vincent Legoll]

Hello

On Wed, Mar 11, 2020 at 4:01 PM Jan Nieuwenhuizen <janneke@gnu.org> wrote:
> +             `(("libcap" ,libcap))  ;capability support is 'ls', etc.

s/is/in/ or s/is/for/ maybe ?

-- 
Vincent Legoll

Re: 15/33: gnu: coreutils: Remove libcap dependency for the Hurd.

[Jan Nieuwenhuizen]

Vincent Legoll writes:

> Hello
>
> On Wed, Mar 11, 2020 at 4:01 PM Jan Nieuwenhuizen <janneke@gnu.org> wrote:
>> +             `(("libcap" ,libcap))  ;capability support is 'ls', etc.
>
> s/is/in/ or s/is/for/ maybe ?

Yes, probably.  Typo fixed in upcoming patch series; thanks :)

janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: 15/33: gnu: coreutils: Remove libcap dependency for the Hurd.

[Ludovic Courtès]

Jan Nieuwenhuizen <janneke@gnu.org> skribis:

> commit 7653827b8919ad85d025ba1a701ba38ab7d2e388
> Author: Jan Nieuwenhuizen <janneke@gnu.org>
> Date:   Sat Mar 7 03:53:38 2020 -0500
>
>     gnu: coreutils: Remove libcap dependency for the Hurd.
>     
>     * gnu/packages/linux.scm (libcap)[supported-systems]: Remove the Hurd.
>     * gnu/packages/base.scm (coreutils)[inputs]: Include libcap only for supported
>     systems.  Fixes building on the Hurd.

LGTM!

bug#40006: 15/33: gnu: coreutils: Remove libcap dependency for the Hurd.

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

> Jan Nieuwenhuizen <janneke@gnu.org> skribis:
>
>> commit 7653827b8919ad85d025ba1a701ba38ab7d2e388
>> Author: Jan Nieuwenhuizen <janneke@gnu.org>
>> Date:   Sat Mar 7 03:53:38 2020 -0500
>>
>>     gnu: coreutils: Remove libcap dependency for the Hurd.
>>     
>>     * gnu/packages/linux.scm (libcap)[supported-systems]: Remove the Hurd.
>>     * gnu/packages/base.scm (coreutils)[inputs]: Include libcap only for supported
>>     systems.  Fixes building on the Hurd.
>
> LGTM!

Pushed to core-updates as 11a5ffba7327250ebe7b67c777204e49858310bb

Yay, my first work for the Hurd just got in \o/
janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: 15/33: gnu: coreutils: Remove libcap dependency for the Hurd.

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

> Jan Nieuwenhuizen <janneke@gnu.org> skribis:
>
>> commit 7653827b8919ad85d025ba1a701ba38ab7d2e388
>> Author: Jan Nieuwenhuizen <janneke@gnu.org>
>> Date:   Sat Mar 7 03:53:38 2020 -0500
>>
>>     gnu: coreutils: Remove libcap dependency for the Hurd.
>>     
>>     * gnu/packages/linux.scm (libcap)[supported-systems]: Remove the Hurd.
>>     * gnu/packages/base.scm (coreutils)[inputs]: Include libcap only for supported
>>     systems.  Fixes building on the Hurd.
>
> LGTM!

Pushed to core-updates as 11a5ffba7327250ebe7b67c777204e49858310bb

Yay, my first work for the Hurd just got in \o/
janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: 27/33: gnu: commencement: glibc-intermediate: Build fixes for the Hurd.

[Ludovic Courtès]

guix-commits@gnu.org skribis:

>                     ;; Tell 'libpthread' where to find 'libihash' on Hurd systems.
> -                   ,@(if (hurd-triplet? (%current-system))
> -                         `((substitute* "libpthread/Makefile"
> -                             (("LDLIBS-pthread.so =.*")
> -                              (string-append "LDLIBS-pthread.so = "
> -                                             (assoc-ref %build-inputs "kernel-headers")
> -                                             "/lib/libihash.a\n"))))
> +                   ,@(if (hurd-system?)
> +                         `(map
> +                           (lambda (f)
> +                            (substitute* f
> +                              (("LDLIBS-pthread.so =.*")
> +                               (string-append "LDLIBS-pthread.so = "
> +                                              (assoc-ref %build-inputs "kernel-headers")
> +                                              "/lib/libihash.a\n")))
> +                            '("sysdeps/mach/Makefile"
> +                              "sysdeps/mach/hurd/Makefile:")))

‘substitute*’ accepts a list of files, so you can write it like this:

  (substitute* '("sysdeps/mach/hurd/Makefile" "sysdeps/mach/Makefile")
    …)

Ludo’.

Re: 27/33: gnu: commencement: glibc-intermediate: Build fixes for the Hurd.

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

>> +                   ,@(if (hurd-system?)
>> +                         `(map
>> +                           (lambda (f)
>> +                            (substitute* f
>
> ‘substitute*’ accepts a list of files, so you can write it like this:
>
>   (substitute* '("sysdeps/mach/hurd/Makefile" "sysdeps/mach/Makefile")
>     …)

Ah nice.  Looking closer I see now that this also avoided rebuilds and
conveniently splices returns a list -- changed to

                   ;; Tell 'libpthread' where to find 'libihash' on Hurd systems.
                   ,(when (hurd-system?)
                      '(substitute* '("sysdeps/mach/Makefile"

suffering a rebuild now anyway.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: 23/33: gnu: commencement: gcc-boot0: Build fix for the Hurd.

[Ludovic Courtès]

guix-commits@gnu.org skribis:

> commit 7a57ca758c590742b63100944f07fddb7290f797
> Author: Jan Nieuwenhuizen <janneke@gnu.org>
> AuthorDate: Sun Mar 1 13:45:42 2020 +0100
>
>     gnu: commencement: gcc-boot0: Build fix for the Hurd.
>     
>     Fixes:
>         g++   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -static-libstdc++ -static-libgcc -Wl,-rpath=/gnu/store/vp2id82a597p119b3wyhhkhd467wvn78-glibc-bootstrap-0/lib -Wl,-dynamic-linker -Wl,/gnu/store/vp2id82a597p119b3w [...]
>             build/genmddeps.o build/read-md.o build/errors.o ../build-i586-unknown-gnu/libiberty/libiberty.a
>         /gnu/store/jk3kx5jwjs9m60svzk6sz79bf0w33l91-binutils-cross-boot0-2.34/bin/ld: build/read-md.o: in function `md_reader::~md_reader()':
>         /tmp/guix-build-gcc-cross-boot0-7.5.0.drv-0/build/gcc/../../gcc-7.5.0/gcc/read-md.c:1049: undefined reference to `operator delete(void*, unsigned int)'
>     
>     This raises the question: Should libstdc++-boot0 (v4.9) be sufficient to build
>     gcc-boot0 (v7.5.0)?

Hmm?  :-)

>     * gnu/packages/commencement.scm (gcc-boot0): Add static library path.

>                 `(,(string-append "LDFLAGS="
> +                                 (if ,(hurd-system?)
> +                                     (string-append
> +                                      "-L" (assoc-ref %build-inputs "gcc") "/lib ")
> +                                     "")

Could you add a comment saying that this is to allow the ‘delete’
operator to be found?  Weird.

That’s it, thanks for the great work!

Ludo’.

Re: 23/33: gnu: commencement: gcc-boot0: Build fix for the Hurd.

[Efraim Flashner]

[-- Attachment #1.1: Type: text/plain, Size: 2447 bytes --]

On Tue, Mar 10, 2020 at 10:13:37AM +0100, Ludovic Courtès wrote:
> guix-commits@gnu.org skribis:
> 
> > commit 7a57ca758c590742b63100944f07fddb7290f797
> > Author: Jan Nieuwenhuizen <janneke@gnu.org>
> > AuthorDate: Sun Mar 1 13:45:42 2020 +0100
> >
> >     gnu: commencement: gcc-boot0: Build fix for the Hurd.
> >     
> >     Fixes:
> >         g++   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -static-libstdc++ -static-libgcc -Wl,-rpath=/gnu/store/vp2id82a597p119b3wyhhkhd467wvn78-glibc-bootstrap-0/lib -Wl,-dynamic-linker -Wl,/gnu/store/vp2id82a597p119b3w [...]
> >             build/genmddeps.o build/read-md.o build/errors.o ../build-i586-unknown-gnu/libiberty/libiberty.a
> >         /gnu/store/jk3kx5jwjs9m60svzk6sz79bf0w33l91-binutils-cross-boot0-2.34/bin/ld: build/read-md.o: in function `md_reader::~md_reader()':
> >         /tmp/guix-build-gcc-cross-boot0-7.5.0.drv-0/build/gcc/../../gcc-7.5.0/gcc/read-md.c:1049: undefined reference to `operator delete(void*, unsigned int)'
> >     
> >     This raises the question: Should libstdc++-boot0 (v4.9) be sufficient to build
> >     gcc-boot0 (v7.5.0)?
> 
> Hmm?  :-)
> 
> >     * gnu/packages/commencement.scm (gcc-boot0): Add static library path.
> 
> >                 `(,(string-append "LDFLAGS="
> > +                                 (if ,(hurd-system?)
> > +                                     (string-append
> > +                                      "-L" (assoc-ref %build-inputs "gcc") "/lib ")
> > +                                     "")
> 
> Could you add a comment saying that this is to allow the ‘delete’
> operator to be found?  Weird.
> 
> That’s it, thanks for the great work!
> 
> Ludo’.
> 

With the bootstrapping efforts going around there's a couple of patches
floating around to change the gcc version for libstdc++-boot0. I've
tested the following patch, which also prepares the way for any other
future supported platforms.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #1.2: 0001-gnu-libstdc-boot0-Use-per-architecture-gcc-versions.patch --]
[-- Type: text/plain, Size: 2014 bytes --]

From 4506c48da7df4397d459337988adbdd54c0d440d Mon Sep 17 00:00:00 2001
From: Efraim Flashner <efraim@flashner.co.il>
Date: Thu, 13 Feb 2020 10:47:34 +0200
Subject: [PATCH 1/2] gnu: libstdc++-boot0: Use per-architecture gcc versions.

* gnu/packages/commencement.scm (libstdc++-boot0): Use a version of gcc
more closely tied to their bootstrap process.
---
 gnu/packages/commencement.scm | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index 2a0a83ad49..b5cb08a19a 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -3,7 +3,7 @@
 ;;; Copyright © 2014 Andreas Enge <andreas@enge.fr>
 ;;; Copyright © 2012 Nikita Karetnikov <nikita@karetnikov.org>
 ;;; Copyright © 2014, 2015, 2017 Mark H Weaver <mhw@netris.org>
-;;; Copyright © 2017, 2018, 2019 Efraim Flashner <efraim@flashner.co.il>
+;;; Copyright © 2017, 2018, 2019, 2020 Efraim Flashner <efraim@flashner.co.il>
 ;;; Copyright © 2018 Tobias Geerinckx-Rice <me@tobias.gr>
 ;;; Copyright © 2018 Jan (janneke) Nieuwenhuizen <janneke@gnu.org>
 ;;; Copyright © 2019 Marius Bakke <mbakke@fastmail.com>
@@ -1427,9 +1427,12 @@ exec " gcc "/bin/" program
 (define libstdc++-boot0
   ;; GCC's libcc1 is always built as a shared library (the top-level
   ;; 'Makefile.def' forcefully adds --enable-shared) and thus needs to refer
-  ;; to libstdc++.so.  We cannot build libstdc++-5.3 because it relies on
-  ;; C++14 features missing in some of our bootstrap compilers.
-  (let ((lib (make-libstdc++ gcc-4.9)))
+  ;; to libstdc++.so.  We therefore use a version of GCC which most closely
+  ;; matches the bootstrap compiler of that architecture.
+  (let ((lib (make-libstdc++
+               (match (%current-system)
+                 ("aarch64-linux" gcc-5)
+                 (_ gcc-4.9)))))
     (package
       (inherit lib)
       (source (bootstrap-origin (package-source lib)))
-- 
2.25.0


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: 23/33: gnu: commencement: gcc-boot0: Build fix for the Hurd.

[Jan Nieuwenhuizen]

Efraim Flashner writes:

> On Tue, Mar 10, 2020 at 10:13:37AM +0100, Ludovic Courtès wrote:
>> guix-commits@gnu.org skribis:
>> 
>> > commit 7a57ca758c590742b63100944f07fddb7290f797
>> > Author: Jan Nieuwenhuizen <janneke@gnu.org>
>> > AuthorDate: Sun Mar 1 13:45:42 2020 +0100
>> >
>> >     gnu: commencement: gcc-boot0: Build fix for the Hurd.
>> >     
>> >     Fixes:
>> >         g++   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -static-libstdc++ -static-libgcc -Wl,-rpath=/gnu/store/vp2id82a597p119b3wyhhkhd467wvn78-glibc-bootstrap-0/lib -Wl,-dynamic-linker -Wl,/gnu/store/vp2id82a597p119b3w [...]
>> >             build/genmddeps.o build/read-md.o build/errors.o ../build-i586-unknown-gnu/libiberty/libiberty.a
>> >         /gnu/store/jk3kx5jwjs9m60svzk6sz79bf0w33l91-binutils-cross-boot0-2.34/bin/ld: build/read-md.o: in function `md_reader::~md_reader()':
>> >         /tmp/guix-build-gcc-cross-boot0-7.5.0.drv-0/build/gcc/../../gcc-7.5.0/gcc/read-md.c:1049: undefined reference to `operator delete(void*, unsigned int)'
>> >     
>> >     This raises the question: Should libstdc++-boot0 (v4.9) be sufficient to build
>> >     gcc-boot0 (v7.5.0)?
>> 
>> Hmm?  :-)
>> 
>> >     * gnu/packages/commencement.scm (gcc-boot0): Add static library path.
>> 
>> >                 `(,(string-append "LDFLAGS="
>> > +                                 (if ,(hurd-system?)
>> > +                                     (string-append
>> > +                                      "-L" (assoc-ref %build-inputs "gcc") "/lib ")
>> > +                                     "")
>> 
>> Could you add a comment saying that this is to allow the ‘delete’
>> operator to be found?  Weird.
>> 
>> That’s it, thanks for the great work!

... I agree, however trying without this and Efraim's patch instead first.

> With the bootstrapping efforts going around there's a couple of patches
> floating around to change the gcc version for libstdc++-boot0. I've
> tested the following patch, which also prepares the way for any other
> future supported platforms.

That looks nice; thanks -- I have added i586-gnu and am trying if that
works for me.

janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: 23/33: gnu: commencement: gcc-boot0: Build fix for the Hurd.

[Jan Nieuwenhuizen]

Jan Nieuwenhuizen writes:

> Efraim Flashner writes:
>
>> On Tue, Mar 10, 2020 at 10:13:37AM +0100, Ludovic Courtès wrote:
>>> guix-commits@gnu.org skribis:
>>> 
>>> > commit 7a57ca758c590742b63100944f07fddb7290f797
>>> > Author: Jan Nieuwenhuizen <janneke@gnu.org>
>>> > AuthorDate: Sun Mar 1 13:45:42 2020 +0100
>>> >
>>> >     gnu: commencement: gcc-boot0: Build fix for the Hurd.
>>> >     
>>> >     Fixes:
>>> >         g++   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -static-libstdc++ -static-libgcc -Wl,-rpath=/gnu/store/vp2id82a597p119b3wyhhkhd467wvn78-glibc-bootstrap-0/lib -Wl,-dynamic-linker -Wl,/gnu/store/vp2id82a597p119b3w [...]
>>> >             build/genmddeps.o build/read-md.o build/errors.o ../build-i586-unknown-gnu/libiberty/libiberty.a
>>> >         /gnu/store/jk3kx5jwjs9m60svzk6sz79bf0w33l91-binutils-cross-boot0-2.34/bin/ld: build/read-md.o: in function `md_reader::~md_reader()':
>>> >         /tmp/guix-build-gcc-cross-boot0-7.5.0.drv-0/build/gcc/../../gcc-7.5.0/gcc/read-md.c:1049: undefined reference to `operator delete(void*, unsigned int)'
>>> >     
>>> >     This raises the question: Should libstdc++-boot0 (v4.9) be sufficient to build
>>> >     gcc-boot0 (v7.5.0)?
>>> 
>>> Hmm?  :-)
>>> 
>>> >     * gnu/packages/commencement.scm (gcc-boot0): Add static library path.
>>> 
>>> >                 `(,(string-append "LDFLAGS="
>>> > +                                 (if ,(hurd-system?)
>>> > +                                     (string-append
>>> > +                                      "-L" (assoc-ref %build-inputs "gcc") "/lib ")
>>> > +                                     "")
>>> 
>>> Could you add a comment saying that this is to allow the ‘delete’
>>> operator to be found?  Weird.

OK!  Yes, I'm reverting to this scenario.  I'm afraid some shared
library doesn't get built and that that's where it usually finds
`delete'.

>>> That’s it, thanks for the great work!
>
> ... I agree, however trying without this and Efraim's patch instead first.
>
>> With the bootstrapping efforts going around there's a couple of patches
>> floating around to change the gcc version for libstdc++-boot0. I've
>> tested the following patch, which also prepares the way for any other
>> future supported platforms.
>
> That looks nice; thanks -- I have added i586-gnu and am trying if that
> works for me.

Well, Marius already convinced you it was a bad idea; but sadly it
didn't work for my hurd problem;  I got

--8<---------------cut here---------------start------------->8---
libtool: compile:  g++ -I/tmp/guix-build-libstdc++-boot0-5.5.0.drv-0/gcc-5.5.0/build/include/ -I/tmp/guix-build-libstdc++-boot0-5.5.0.drv-0/gcc-5.5.0/build/include -I/tmp/guix-build-libstdc++-boot0-5.5.0.drv-0/gcc-5.5.0/libstdc++-v3/libsupc++ -fPIC -DPIC -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=compatibility-condvar.lo -std=gnu++11 -c ../../libstdc++-v3/src/c++11/compatibility-condvar.cc  -fPIC -DPIC -D_GLIBCXX_SHARED -o .libs/compatibility-condvar.o
libtool: compile:  g++ -I/tmp/guix-build-libstdc++-boot0-5.5.0.drv-0/gcc-5.5.0/build/include/ -I/tmp/guix-build-libstdc++-boot0-5.5.0.drv-0/gcc-5.5.0/build/include -I/tmp/guix-build-libstdc++-boot0-5.5.0.drv-0/gcc-5.5.0/libstdc++-v3/libsupc++ -fPIC -DPIC -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=compatibility-condvar.lo -std=gnu++11 -c ../../libstdc++-v3/src/c++11/compatibility-condvar.cc -o compatibility-condvar.o >/dev/null 2>&1
make[3]: *** No rule to make target '../src/c++98/libc++98convenience.la', needed by 'libstdc++.la'.  Stop.
make[3]: Leaving directory '/tmp/guix-build-libstdc++-boot0-5.5.0.drv-0/gcc-5.5.0/build/src'
make[2]: *** [Makefile:637: all-recursive] Error 1
make[2]: Leaving directory '/tmp/guix-build-libstdc++-boot0-5.5.0.drv-0/gcc-5.5.0/build/src'
make[1]: *** [Makefile:507: all-recursive] Error 1
make[1]: Leaving directory '/tmp/guix-build-libstdc++-boot0-5.5.0.drv-0/gcc-5.5.0/build'
make: *** [Makefile:414: all] Error 2
command "make" "-j" "1" failed with status 2
--8<---------------cut here---------------end--------------->8---

another terrible error.  We could use some glibc and gcc developers
helping with out bootstrap, packaging and cross builds!

janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: 23/33: gnu: commencement: gcc-boot0: Build fix for the Hurd.

[Efraim Flashner]

On March 11, 2020 2:27:37 PM UTC, Jan Nieuwenhuizen <janneke@gnu.org> wrote:
>Jan Nieuwenhuizen writes:
>
>> Efraim Flashner writes:
>>
>>> On Tue, Mar 10, 2020 at 10:13:37AM +0100, Ludovic Courtès wrote:
>>>> guix-commits@gnu.org skribis:
>>>> 
>>>> > commit 7a57ca758c590742b63100944f07fddb7290f797
>>>> > Author: Jan Nieuwenhuizen <janneke@gnu.org>
>>>> > AuthorDate: Sun Mar 1 13:45:42 2020 +0100
>>>> >
>>>> >     gnu: commencement: gcc-boot0: Build fix for the Hurd.
>>>> >     
>>>> >     Fixes:
>>>> >         g++   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -static-libstdc++ -static-libgcc -Wl,-rpath=/gnu/store/vp2id82a597p119b3wyhhkhd467wvn78-glibc-bootstrap-0/lib -Wl,-dynamic-linker -Wl,/gnu/store/vp2id82a597p119b3w [...]
>>>> >             build/genmddeps.o build/read-md.o build/errors.o ../build-i586-unknown-gnu/libiberty/libiberty.a
>>>> >         /gnu/store/jk3kx5jwjs9m60svzk6sz79bf0w33l91-binutils-cross-boot0-2.34/bin/ld: build/read-md.o: in function `md_reader::~md_reader()':
>>>> >         /tmp/guix-build-gcc-cross-boot0-7.5.0.drv-0/build/gcc/../../gcc-7.5.0/gcc/read-md.c:1049: undefined reference to `operator delete(void*, unsigned int)'
>>>> >     
>>>> >     This raises the question: Should libstdc++-boot0 (v4.9) be sufficient to build
>>>> >     gcc-boot0 (v7.5.0)?
>>>> 
>>>> Hmm?  :-)
>>>> 
>>>> >     * gnu/packages/commencement.scm (gcc-boot0): Add static library path.
>>>> 
>>>> >                 `(,(string-append "LDFLAGS="
>>>> > +                                 (if ,(hurd-system?)
>>>> > +                                     (string-append
>>>> > +                                      "-L" (assoc-ref %build-inputs "gcc") "/lib ")
>>>> > +                                     "")
>>>> 
>>>> Could you add a comment saying that this is to allow the ‘delete’
>>>> operator to be found?  Weird.
>
>OK!  Yes, I'm reverting to this scenario.  I'm afraid some shared
>library doesn't get built and that that's where it usually finds
>`delete'.
>
>>>> That’s it, thanks for the great work!
>>
>> ... I agree, however trying without this and Efraim's patch instead first.
>>
>>> With the bootstrapping efforts going around there's a couple of patches
>>> floating around to change the gcc version for libstdc++-boot0. I've
>>> tested the following patch, which also prepares the way for any other
>>> future supported platforms.
>>
>> That looks nice; thanks -- I have added i586-gnu and am trying if that
>> works for me.
>
>Well, Marius already convinced you it was a bad idea; but sadly it
>didn't work for my hurd problem;  I got
>
>--8<---------------cut here---------------start------------->8---
>libtool: compile:  g++ -I/tmp/guix-build-libstdc++-boot0-5.5.0.drv-0/gcc-5.5.0/build/include/ -I/tmp/guix-build-libstdc++-boot0-5.5.0.drv-0/gcc-5.5.0/build/include -I/tmp/guix-build-libstdc++-boot0-5.5.0.drv-0/gcc-5.5.0/libstdc++-v3/libsupc++ -fPIC -DPIC -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=compatibility-condvar.lo -std=gnu++11 -c ../../libstdc++-v3/src/c++11/compatibility-condvar.cc  -fPIC -DPIC -D_GLIBCXX_SHARED -o .libs/compatibility-condvar.o
>libtool: compile:  g++ -I/tmp/guix-build-libstdc++-boot0-5.5.0.drv-0/gcc-5.5.0/build/include/ -I/tmp/guix-build-libstdc++-boot0-5.5.0.drv-0/gcc-5.5.0/build/include -I/tmp/guix-build-libstdc++-boot0-5.5.0.drv-0/gcc-5.5.0/libstdc++-v3/libsupc++ -fPIC -DPIC -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=compatibility-condvar.lo -std=gnu++11 -c ../../libstdc++-v3/src/c++11/compatibility-condvar.cc -o compatibility-condvar.o >/dev/null 2>&1
>make[3]: *** No rule to make target '../src/c++98/libc++98convenience.la', needed by 'libstdc++.la'.  Stop.
>make[3]: Leaving directory '/tmp/guix-build-libstdc++-boot0-5.5.0.drv-0/gcc-5.5.0/build/src'
>make[2]: *** [Makefile:637: all-recursive] Error 1
>make[2]: Leaving directory '/tmp/guix-build-libstdc++-boot0-5.5.0.drv-0/gcc-5.5.0/build/src'
>make[1]: *** [Makefile:507: all-recursive] Error 1
>make[1]: Leaving directory '/tmp/guix-build-libstdc++-boot0-5.5.0.drv-0/gcc-5.5.0/build'
>make: *** [Makefile:414: all] Error 2
>command "make" "-j" "1" failed with status 2
>--8<---------------cut here---------------end--------------->8---
>
>another terrible error.  We could use some glibc and gcc developers
>helping with out bootstrap, packaging and cross builds!
>
>janneke
>

If you're using gcc-7 as the bootstrap gcc for the Hurd then IMO you should go ahead and either use gcc-7 or gcc for the libstdc++-boot0
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: 23/33: gnu: commencement: gcc-boot0: Build fix for the Hurd.

[Jan Nieuwenhuizen]

Efraim Flashner writes:

> If you're using gcc-7 as the bootstrap gcc for the Hurd then IMO you
> should go ahead and either use gcc-7 or gcc for the libstdc++-boot0

Ah...your patch but then with gcc-7 instead of gcc-5; gosh why didn't I
think of that.  Thank you!

I'll give that a try...although that patch won't get in, in its current
form, right?  We'd have to think of some solution...

janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: 23/33: gnu: commencement: gcc-boot0: Build fix for the Hurd.

[Efraim Flashner]

On March 11, 2020 4:20:26 PM UTC, Jan Nieuwenhuizen <janneke@gnu.org> wrote:
>Efraim Flashner writes:
>
>> If you're using gcc-7 as the bootstrap gcc for the Hurd then IMO you
>> should go ahead and either use gcc-7 or gcc for the libstdc++-boot0
>
>Ah...your patch but then with gcc-7 instead of gcc-5; gosh why didn't I
>think of that.  Thank you!
>
>I'll give that a try...although that patch won't get in, in its current
>form, right?  We'd have to think of some solution...
>
>janneke
>

For new architectures it can go in, but there's no actual need for it for aarch64
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: 23/33: gnu: commencement: gcc-boot0: Build fix for the Hurd.

[Jan Nieuwenhuizen]

Efraim Flashner writes:

> On March 11, 2020 4:20:26 PM UTC, Jan Nieuwenhuizen <janneke@gnu.org> wrote:
>>Efraim Flashner writes:
>>
>>> If you're using gcc-7 as the bootstrap gcc for the Hurd then IMO you
>>> should go ahead and either use gcc-7 or gcc for the libstdc++-boot0
>>
>>Ah...your patch but then with gcc-7 instead of gcc-5; gosh why didn't I
>>think of that.  Thank you!
>>
>>I'll give that a try...although that patch won't get in, in its current
>>form, right?  We'd have to think of some solution...
>>
>>janneke
>>
>
> For new architectures it can go in, but there's no actual need for it
> for aarch64

Tried to try this

(define libstdc++-boot0
  ;; GCC's libcc1 is always built as a shared library (the top-level
  ;; 'Makefile.def' forcefully adds --enable-shared) and thus needs to refer
  ;; to libstdc++.so.  We therefore use a version of GCC which most closely
  ;; matches the bootstrap compiler of that architecture.
  (let ((lib (make-libstdc++
              (match (warn 'CS: (or (%current-target-system)
                                    (%current-system)))
                 ("i586-gnu" gcc-7)
                 (_ gcc-4.9)))))

overnight, but I realised that this diversification does not work; CS is
still x86_64-linux here when cross building for the Hurd.

janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com