Re: Building grep 2.9 on SunOS 4

[Eric Blake]

On 02/04/2012 06:44 AM, Michael Haardt wrote:
>>> I am afraid that being active maintainer asks for more time than I have
>>
>> That's quite understandable.  I used SunOS 4 heavily, but
>> it's now just a museum piece, and it doesn't appear to be
>> worth your time or ours to maintain GNU utilities on it.
>> (If the best way to run an environment is on an emulator,
>> that's a good sign the environment is no longer real....)
> 
> To make things clear: "Active maintainer" means to make sure any new
> version of gnulib runs perfectly on the system.  I can't do that, but
> I can send small patches to fix problems with SunOS that I apply anyway
> to get certain packages using gnulib running for me, like grep.  Where
> can I send such patches?
> 
> So far, it did not take much for grep, m4 and gawk.  Some examples:
> 
> --- grep-2.9/lib/hash.h 2011-04-14 09:33:10.000000000 +0200
> +++ ./grep-2.9-hacked/lib/hash.h        2012-02-01 23:11:12.000000000 +0100
> @@ -26,7 +26,7 @@
>  
>  # include <stdio.h>
>  # include <stdbool.h>
> -
> +# include <stddef.h>

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.

> Otherwise size_t is not declared.  Then it would help an awful lot if
> the check for a missing memmove could be put back in, along with memmove
> itself.

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.

> 
> 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.

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature