Re: porting to NeXTstep

[Bruno Haible]

Hi Daniel,

>   Also, the test program needs string.h and stdlib.h (for strerror() and
>   getenv(), respectively)
>
> * Fixed apparent typos in shell test(1) logic in modules/popen

Thanks for these two. I committed them in your name:

2011-10-14  Daniel Richard G.  <address@hidden>  (tiny change)

        popen: Fix dependency conditions.
        * modules/popen (Depends-on, configure.ac): Fix shell syntax error.

2011-10-14  Daniel Richard G.  <address@hidden>  (tiny change)

        perror: Fix autoconf test.
        * m4/perror.m4 (gl_FUNC_PERROR): In the test program, include
        <stdlib.h> and <string.h>.

The "tiny change" only means that the change was small enough that it
did not warrant a copyright assignment from you to the FSF (paperwork).

In git log, your committer name comes out as
"Daniel Richard G <address@hidden>"
aithough I used the option --author="Daniel Richard G. <address@hidden>".
I don't know how to make 'git' preserve the trailing period.

> I found that --megatest was a bit unwieldy to work with!

Yes. --megatest is mostly useful for two purposes only:
  - Check whether the 'Files' list in the modules descriptions is
    complete.
  - See whether the link dependencies of test programs are complete.

> * "checking whether frexp works": frexp() goes into an infinite loop
>   when its argument is infinite, so ./conftest has to be killed for
>   configure to move on. (Granted, this could be a quirk of running under
>   VirtualBox...)

Yes, it could be. I've seen strange floating-point results under QEMU;
it could well be that VirtualBox has flaws in the same area.

> * "checking whether perror matches strerror": strerror(-1) returns an
>   invalid pointer, and attempting to puts() this yields SIGBUS.
>   (Wouldn't it be safer to pass EPERM or something similarly universal?)

This is the purpose of the test: testing whether you can safely pass
invalid error number, such as -1, to strerror.

>   (Is there a good way to write that m4 code so that the #include
>   directives aren't indented in the generated source? The "#" really
>   ought to be in the first column...)

All C and C++ compilers newer than SunOS 4 cc support any amount of spaces
before and after the '#' in preprocessor directives. We are taking
advantage of this fact, indenting the entire programs in files such as
perror.m4. We don't care about the amount of whitespace that gets added
to the generated 'configure' file.

> * The bundled compiler (NeXT-modified gcc 2.5.8) doesn't know about
>   asm labels (http://gcc.gnu.org/onlinedocs/gcc/Asm-Labels.html),
>   erroring out with
> 
>     ./stdio.h:1154: illegal function definition, found `asm'
> 
>   I didn't see an easy way around this other than -U__GNUC__ (!)

This is an easy fruit: I used the condition
  #  if defined __GNUC__
in stdio.in.h. It could be refined if we know the first GCC version
which supports this 'asm' syntax. Versions of GCC older than 2.95
are not on my radar, but if you want to make the effort of
  - downloading gcc 2.5.8, 2.6.x, 2.7.2.1, 2.91, 2.92, 2.93, 2.94,
  - looking in each version's documentation whether the asm keyword
    can be used to "rename" a function,
to find out this first GCC version that supported it, we can fix
the #if condition.

> * The preprocessor doesn't like e.g. "#if !__STRICT_ANSI__", so replaced
>   with "#if !(__STRICT_ANSI__ + 0)". (Shouldn't this really be "#if
>   !defined(__STRICT_ANSI__)"?)

Is this GCC version defining __STRICT_ANSI__ to empty, or is it unable
to evaluate unknown identifiers to 0 in preprocessor expressions? In
the first case, you could add -D__STRICT_ANSI__=0 to your CPPFLAGS.
But in the second case, all hope is lost, because we do
   #if !HAVE_FOOBAR
in hundreds of places.

>   ("cc -E -traditional-cpp" yielded a parse error on this, but "cc -c"
>   actually hangs)

Yes, this -traditional-cpp option was OK in GCC versions from the FSF
but broken in NeXTstep GCC.

> * strcoll() on this system takes *three* arguments:
> 
>     size_t strcoll(char *to, size_t maxsize, const char *from);
>
> * EILSEQ doesn't exist here

These could be rather easily worked around with gnulib techniques.

>   (The system has rewinddir(), but in -lposix)

You could set LIBS="-lposix" when configuring.

>   (Setting LIBS=-lposix isn't an option, alas, as this produces broken
>   binaries that fail instantly with "Floating point exception")

Oh shit...

> * sigaction() et al. are in the headers, but require -lposix to link
> 
>   This leads to a problem in gllib's signal.h

The bigger problem is that <sys/wait.h> contains old-BSD-style macros
and function declarations, IIRC.

> * C++ support is completely, utterly FUBAR. No namespaces! Dropped
>   --with-c++-tests.

Very understandable. NeXTstep was released in 1992-1995, whereas namespaces
were added in C++ around 1998.

> In a nutshell, the configure script now works with no visible breakage,
> and most of the objects (though not all) build cleanly. It certainly got
> a lot farther than I expected!

Good. But I didn't see the sleep/alarm workaround in your gnulib-fixes.patch?

> As for the remaining errors, some of them might be interesting corner
> cases. I'd be happy to test any changes you might want to try out.

Thanks for the offer, but it would not be a worthy use of your time :-)

Bruno
-- 
In memoriam Robert Dziekański <http://en.wikipedia.org/wiki/Robert_Dziekański>