Tru64 and 2.2 problems

[Rob Siemborski]

On Tue, 22 Jul 2003, Scott Adkins wrote:

> With respect to the compile errors, this is what I have found:
>
>  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.

Please bugzilla this and hopefully we can come up with a better configure
system for it.

>     Basically, ever line in that table generates an error on the union
>     construct.  I don't understand the error message, been even more so, I
>     don't understand why the union is even there at all.  It appears that
>     this file is automatically generated by the following command:

The union is there because the default value can be either an int or a
char *.

>       ../tools/config2header imapopts.c imapopts.h < imapoptions
>
>     The config2header script talks about playing an interesting game to get
>     the union to initialize itself in a syntacticly valid manner, namely to
>     initialize the union itself and not the members of the union, as well as
>     to ensure that the union is initialized to something of a type that is
>     in that union.  What do I say about that?  Very bizarre, and it doesn't
>     work in Tru64.

If you have a suggestion that results in something that compiles with gcc
also, please let me know.

>     Doing a mass delete of all the '(union config_value)' stuff in the file
>     gets the code to compile, but I don't know what kind of problems that
> is
>     going to cause me if it has to do with initializing things.
>
>     Any thoughts on how to handle this problem?

I'm not sure what you're deleting here, so I can't say if its going to
work or not.  If the values are still there, I'll cautioiusly claim that
it will work.

>  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?

What does this look like after your preprocessor sees it?  The contents of
the __attribute__ *should* dissapear if your compiler doesn't support it
and the semicolon should be able to be anywhere as long as its the next
token.

> Anyways, I hope someboyd out there can throw some ideas out to me... What I
> see right now is a server that acts slower than the 2.0.16 version we were
> running, and we are having problems with it staying up too.  I am still
> troubleshooting those problems.

I thought you said it wasn't running at all?

I'm not sure what to do about your runpath problems, since I don't know
anyone who has their sasl libraries and Berkeley DB libraries and so on
all live in a single directory.

As much as I want to be as portable as possible, is there a reason you
can't use gcc for this?  I'm not going to be able to do much for you
unless you can get me patches, since I don't have any Tru64 machines to
work on.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper