Tru64 and 2.2 problems

[Robert Urban]

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