pcontrol compilation fails on G4 with MacOS 10.4.11

[Sebastian Jester]

Ohana refuses to compile on my G4 with MacOS 10.4.11. There's a preprocessing problem in pcontrol.h, both in the Ohana from the standalone tarball
​http://kiawe.ifa.hawaii.edu/eugene/downloads/Ohana.20081024.tgz
and in Ohana exported from svn with -r {2009-04-14}

The problem occurs because pcontrol.h has a typedef struct { ... } Job; and in that typedef, the following fields are defined:

  JobOutput    stdout;
  JobOutput    stderr;

However, on my G4 MacOS 10.4.11, /usr/include/stdio.h contains the following defines:

#define stdout  (&__sF[1])
#define stderr  (&__sF[2])

so that those apparently innocuous lines get turned into

  JobOutput (&__sF[1]);
  JobOutput (&__sF[2]);

It looks like adding a compiler flag
-D__DARWIN_UNIX03=1
fixes this; maybe also -D__DARWIN_UNIX03=0 is what's needed (according to ​http://trac.macports.org/ticket/13963 ). I get 'multiple symbol definition' errors after that, but I can at least start and exit pcontrol.

However, I don't know how to tell psbuild to use that flag, and we should test that pcontrol indeed works with this additional compiler flag.

The error message was:

gcc -g -O0 -D_DARWIN_C_SOURCE -Wall -Werror  -I/Users/jester/usrdevel/ipp/Ohana/src/opihi/include -I/Users/jester/psconfig/Ohana-mybranch.darwin/include -I/usr/include -I/usr/local/include -I/Users/jester/psconfig//Ohana-mybranch.darwin/include  -Ddarwin -c /Users/jester/usrdevel/ipp/Ohana/src/opihi/pcontrol/delete.c -o /Users/jester/usrdevel/ipp/Ohana/src/opihi/pcontrol/delete.darwin.o
In file included from /Users/jester/usrdevel/ipp/Ohana/src/opihi/pcontrol/delete.c:1:
/Users/jester/usrdevel/ipp/Ohana/src/opihi/include/pcontrol.h:111: error: parse error before '&' token
cc1: warnings being treated as errors

[Sebastian Jester]

I found that I can indeed fix this compilation problem by adding

-D__DARWIN_UNIX03=1

to the CFLAGS and defines in Ohana's configure.tcsh (and also by using the ncurses from extlibs instead of the Mac's one). I think I have even fiddled things properly so that configure.tcsh only does that for darwin but not darwin_x86, which seems like the right thing to do. However, I have no idea how to do it globally in the psbuild system; I found stdout or stderr symbols occur also in a number of other places (via grep of the entire IPP tree, see output below) and I think the same thing will happen there.

Changing this globally is probably low-priority, because there probably aren't many G4 macs around where IPP will be run, but there might be; and there also might be a few people with Powerbook laptops like mine who might at least want to install Ohana. So at least I wanted to archive this information so people can find out here what's going wrong if they run into compile problems; if many people re-encounter this problem, it would be worth making also a global change.

Here is the list of all occurrences of stdout/stderr that are or could be affected by the #define stdout/stderr in stdio.h, which I believe could be fixed by defining the -D flag above when compiling on darwin (but not darwin_x86):

./Ohana/src/addstar/include/addstar.h:    fprintf (stderr, "ERROR:  photcode %s not found in photcode table\n", NAME); \
./Ohana/src/gophot/include/fit.h:      fprintf(stderr,"failed to malloc X\n");\
./Ohana/src/gophot/include/fit.h:       fprintf(stderr,"failed to realloc X\n"); \
./Ohana/src/libfits/extern/ricecomp.h:#define ffpmsg(MSG) fprintf(stderr, "%s\n", MSG)
./Ohana/src/libohana/include/ohana.h:    fprintf (stderr, "failed to open %s\n", NAME); \
./Ohana/src/libohana/include/ohana_allocate.h:    fprintf(stderr,"failed malloc at %d in %s\n", __LINE__, __FILE__);\
./Ohana/src/libohana/include/ohana_allocate.h:    fprintf(stderr,"failed realloc at %d in %s\n", __LINE__, __FILE__);\
./Ohana/src/libohana/include/ohana_allocate.h:      fprintf(stderr,"failed realloc increment at %d in %s\n", __LINE__, __FILE__);\
./Ohana/src/opihi/include/pcontrol.h:  JobOutput    stdout;
./Ohana/src/opihi/include/pcontrol.h:  JobOutput    stderr;
./psLib/test/pstap/src/pstap.h:#define done() ok(psMemCheckLeaks(0, NULL, stdout, false) == 0, "Memory Leaks"); \
./psLib/test/pstap/src/pstap.h:# define mem() ok(psMemCheckLeaks(psMemGetLastId(), NULL, stdout, false) == 0, "Memory Leaks")
./psLib/test/pstap/src/pstap.h:    fprintf(stdout, __VA_ARGS__); \
./psLib/test/pstap/src/pstap.h:    fprintf(stdout, "\n[%s:%d in %s]\n", __FILE__, __LINE__, __func__); \
./psModules/test/pstap/src/pstap.h:#define done() ok(psMemCheckLeaks(0, NULL, stdout, false) == 0, "Memory Leaks"); return exit_status()
./psModules/test/pstap/src/pstap.h:        # define mem() ok(psMemCheckLeaks(psMemGetLastId(), NULL, stdout, false) == 0, "Memory Leaks")

[eugene]

It sounds like elements of a structure should probably not have names which may be reserved and sometimes modified by the pre-processor.

I have checked in a change (r28242) in which the elements of the pcontrol Job structure are renamed from stdout,stderr to stdout_buf,stderr_buf.

I suspect this fixes this problem, but I do not have an appropriate testing platform.