Re: bootstrapping SED-4.5, circular dependency?

[Assaf Gordon]

Hello,

On 2018-12-08 6:46 a.m., Jan Nieuwenhuizen wrote:
> Now that we have successfully bootstrapped GuixSD without using Gcc,
> Binutils, GNU C lib, I am working to remove other binary bootstrap
> seeds; such as SED and GZIP.
>
> I have bootstrapped GNU make and Bash and was looking into building
> GZIP, only to find out that it depends on a SED feature that our
> bootstrap-gash does not provide.
>
> So, I figured that SED should be built before GZIP, but I found that
> SED-4.5 depends on the same SED feature that GZIP needs...apparently
> a circular dependency?

Technically speaking, these kind of dependencies (e.g. needing SED
to build a package) arise from autotools, not directly from sed's build 
commands.


> Here is what I get:
[...]
> ERROR: In procedure scm-error:
> SED: command not supported: "/^.*\\/\\([^/][^/]*\\)\\/*$/{\n\t    s//\\1/\n\t    
> q\n\t  }\n\t  /^X\\/\\(\\/\\/\\)$/{\n\t    s//\\1/\n\t    q\n\t  }\n\t  
> /^X\\/\\(\\/\\).*/{\n\t    s//\\1/\n\t    q\n\t  }\n\t  s/.*/./; q"

The failed sed program is (transcribed from the above error message)
====
/^.*\/\([^/][^/]*\)\/*$/{
            s//\1/
            q
          }
  /^X\/\(\/\/\)$/{
            s//\1/
            q
  }
  /^X\/\(\/\).*/{
            s//\1/
            q
  }
  s/.*/./; q
====

It is a very standard sed program, which should (and does) work on every
existing SED implementation (posix-compliant of course).

> The SED throwing this error is the minimal SED from Gash, that I
> implemented in GNU Guile.

I would recommend adjusting your sed implementation to support
these commands, because you'll encounter them in many packages
that use autotools.

> Do you know whether bootstrapping of GZIP and/or SED is supported? 

It is supported in the sense that almost any old sed implementation
can be used (e.g. you can build GNU sed if you only have BSD sed
or AIX sed or busybox sed).

> Can
> you advise me on my next step (looking to bootstrap an earlier SED --
> which version? or an earlier GZIP -- which version?)

Digging a bit further, I see this specific sed program originates
from autoconf, from the M4 code used to implement basename and dirname,
e.g. here:
https://git.savannah.gnu.org/cgit/autoconf.git/tree/lib/m4sugar/m4sh.m4#n922
https://git.savannah.gnu.org/cgit/autoconf.git/tree/lib/m4sugar/m4sh.m4#n970

So it means every autotools package that uses these macros (and there
are many) will cause the same issue.

The best solution is likely to implement these sed commands in your
sed implementation (if you need help in testing I'm happy to try,
though I know very little about guile).

Second best would likely be to investigate with autotools developers
how to avoid this. Perhaps have a specific flag to autoconf to skip
generation of these portability m4 macros, since you know guix's 
basename/dirname are good enough ?


As a last resort, I can think of a really ugly hack:
create a "fake sed" wrapper script in guile,
that checks if the given SED script is one that you don't implement
(e.g. the one above). If it is, since we know all it does is 
basename/dirname - just call a real dirname/basename instead of
using sed's regexes. Otherwise, pass the parameters to the real
guile-sed.
Put this guile-sed-wrapper in $PATH, and it might just work...


In a completely different approach, since you are trying to bootstrap:
building OpenBSD's sed binary is very easy (needs just a C compiler and 
works fine on GNU/Linux) - perhaps building it
would be faster as a first step to get a working sed, then use it
to build other packages (I can help with that if you want, send me an 
email).


regards,
 - assaf