On Thu, 3 Jun 2004, Ilja Booij wrote:
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.
Cool. Thanks!
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)
Thanks again :)
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!)
Thanks!
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..
the following line from the dbmail/Makefile.in:
$(COMPILE) -Wp,-MD,.deps/$(*F).pp -c $<
the -Wp,-MD,.deps/$(*F).pp options are GCC specific.
I'm not sure what we need to do to generate them portably using
the native toolset.
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
