[CCing bug-gnulib.]
Daniel Richard G. wrote:
> I was recently playing around with a NeXTSTEP 3.3 system in a virtual
> machine. Among other things, I tried compiling various modern-day source
> packages to see how well they work.
>
> In building wget, I found a relatively minor problem in
> gl_ABSOLUTE_HEADER_ONE: the bundled sed does not understand e.g.
> '\#/sys/socket.h#{...}', but it does do '/\/sys\/socket.h/{...}'.
>
> [...]
> checking whether stat is declared without a macro... yes
> checking whether utimensat is declared without a macro... no
> checking absolute name of <sys/types.h>... Unrecognized command:
> \#/sys/types.h#{
> ""
> checking absolute name of <sys/uio.h>... Unrecognized command: \#/sys/uio.h#{
> ""
> checking absolute name of <sys/wait.h>... Unrecognized command:
> \#/sys/wait.h#{
> ""
> checking whether waitpid is declared without a macro... no
> checking absolute name of <unistd.h>... Unrecognized command: \#/unistd.h#{
> ""
> checking whether chown is declared without a macro... no
> checking whether dup2 is declared without a macro... no
> [...]
>
> See the attached patch, against gnulib git. NeXTSTEP may be long dead,
> but I figure, there's no harm in keeping compatibility---and if not, the
> configure script should probably check that the construct is supported
> and error out rather than run incorrectly. (Some packages did bomb out
> on the "looking for a sed that doesn't truncate lines" check.)
Hi,
Gnulib attempts to target computer systems from this era, see
<https://www.gnu.org/software/gnulib/manual/html_node/Target-Platforms.html>.
NeXTstep had its highlight time from 1992 to 1995; that is way too old for
gnulib to support.
And the workaround for you is simple: Just install a version of GNU sed 3.02
in your PATH, and you'll be done.
Your patch replaces 1 line of code with 4 lines of code and is the kind of
complexity we want to avoid if we can.
Bruno
--
In memoriam Bekir Çoban-zade <http://en.wikipedia.org/wiki/Bekir_Çoban-zade>
