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