bug-gnulib
[Top][All Lists]
Advanced

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

Re: Building grep 2.9 on SunOS 4


From: Michael Haardt
Subject: Re: Building grep 2.9 on SunOS 4
Date: Sat, 04 Feb 2012 16:22:31 +0100
User-agent: Heirloom mailx 12.1 6/15/06

> Wrong place for the fix.  POSIX requires that inclusion of <stdio.h>
> exposes size_t.  Therefore, the real fix is to make the gnulib
> replacement header stdio.in.h pull in <stddef.h> to define size_t when
> building for SunOS4; at which point every single other file that relies
> on the POSIX requirement, like hash.h, will work out of the box.

Good point! Grep does include <stdio.h>, but it does not contain a
stdio.in.h file.  Should it?

> The memmove module was marked obsolete (meaning it is only useful on
> unsupported machines, because no modern system has any bugs in it).  Any
> package that still wants to compile on SunOS4 merely need request use of
> the obsolete modules after all.  Same story for atexit.

Interesting.  What would I need to do with the grep source for changing that
locally?

> > A slightly more complicated issue is in src/dfa.c.  The is* functions are
> > used, but they are macros on SunOS4 and if you undefine them (which is
> > not the case in src/dfa.c), you find there are no functions of the same
> > name in libc.  In fact I am used to that from other older systems as well,
> > so making that more portable would be useful for others, too.
>
> Gnulib could indeed work around this (there are other cases where gnulib
> provides functions as required by POSIX when the library provided only
> macros), but again, someone has to do the work, and it won't be me
> because I don't have access to a SunOS4 platform.  Furthermore, such a
> module would probably be marked obsolete, so again, you're back at the
> situation of needing to explicitly request obsolete modules before a
> package would target SunOS4.

If there is a rather standardized way how to include obsolete modules
for a GNU package to ease the job, then that's a very nice solution to
the problem for those who still run systems requiring them.

Michael



reply via email to

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