Hi Larry,
Larry Rosenman wrote:
On Thu, 3 Jun 2004, Ilja Booij wrote:
Larry Rosenman wrote:
Is the DBMail developers interested in NON-GCC compiles on UnixWare?
I like to be as portable as possible.
I had to change all __FUNCTION__ to __func__ (which is the way
C99 spells it), as well as comment out the __attribute__ lines.
I just checked, and __func__ also works on gcc. If __func__ is standard in
C99, and works in gcc, we might as well replace all instances of
__FUNCTION__ with __func__
Yes, I believe that it should be __func__ if GCC supports it. (I use
the native compiler on UnixWare).
I'll change this.
The __attribute__ lines are GCC dependent and should be surrounded by
preprocessor guards. This is done correctly in dbmail.h (example below), but
not in all places.
#ifdef __GNUC__
#define UNUSED __attribute__((__unused__))
#else
#define UNUSED
#endif
There are a number of source (.c) files that have bare __attribute__ lines, and
should be protected with #ifdef __GNUC__/#endif.
Done (CVS is updated)
yes, this (setlinebuf()) should probably be done using autoconf.
The manpage for setlinebuf states the following:
The setlinebuf function is exactly equivalent to the call:
setvbuf(stream, (char *)NULL, _IOLBF, 0);
Does setvbuf() work on UnixWare? If so, we can change the calls to
setlinebuf() (both in serverchild.c) to setvbuf() like above.
Yes, setvbuf() is in the native libc, and should be used in place of
the UCB(BSD) setlinebuf() call.
I believe setvbuf is ANSI C, and setlinebuf() is a BSDism.
OK, I'll change setlinebuf() to setvbuf() (I'll check if it works of
course!)
Oh, I also needed to remove the -fomit-frame-pointer option
as it's not valid on UnixWare.
This would be an autoconf thingie.
Yes, and if you aren't using GCC.
One thing I forgot is the dependency generation the makefiles use
GCC-specific options which don't work in UnixWare's native cc, and
should be more portably defined for the non-GCC compilers.
Can you give examples? I'm not entirely sure what you mean..
Ilja
