Scott Adkins wrote: > 1) The configure process appears to pick up on the fact that Tru64 does > have getnameinfo(), but not getaddrinfo(). The problem is that if one > is found and the other is not, the definitions for both are included > in lib/gai.h. Well, getnameinfo() on Tru64 has a slightly different > definition and produces a conflict that the compiler can't resolve. > The solution was to modify gai.h and wrap the getaddrinfo() related > routines with "#ifndef HAVE_GETADDRINFO/#endif" macros, and wrap the > getnameinfo() with similar HAVE_GETNAMEINFO macros.
Tru64 does indeed have a getaddrinfo, it even has two. You must #include <netdb.h> in order to pull in the appropriate definition. The designers of Tru64 bent over backwards trying to be as standards-compatible as humanly possible. Because the standards (4.4/4.3 BSD) define contradictory behaviour for getaddrinfo, you must say what you want. By default you get 4.3BSD behaviour. If you want 4.4BSD, you must define _XOPEN_SOURCE_EXTENDED before you #include <netdb.h>. See standards(5) for more information on these things... > 3) After that, it compiles for awhile and then stops on imap/protocol.c > with the following error: > > cc: Error: ./../lib/prot.h, line 209: Missing ";". (nosemi) > __attribute__ ((format (printf, 2, 3))); > > Looking in lib/prot.h, I see the following: > > extern int prot_printf(struct protstream *, const char *, ...) > __attribute__ ((format (printf, 2, 3))); > > What is that supposed to do? I simply deleted the line that has the > __attribute__ on it and put a semicolon on the previous line and it > compiles. What problems will I see by doing that? I don't have any specific suggestions wrt to the problems above, but cc -source_listing -show all [other flags] sourcefile.c is your *friend*. It produces sourcefile.lis which can be immensely helpful. cheers, Rob Urban