I also compiled cyrus-imapd-2.2.1-BETA on a Solaris 9 box with Forte C compiler. I had some of the same problems, which come from the fact that cyrus is mostly gcc compiler oriented.
> 2) So, I get past the above, and run right smack into another problem, > this time with lib/imapopts.c. I get over a 100 lines of errors along > the lines of the following: > > {IMAPOPT_ADMINS,"admins",0,(union config_value)((const char > *)""),OPT_STRING}, > ---------------------------^ > {IMAPOPT_ALLOWALLSUBSCRIBE,"allowallsubscribe",0,(union > config_value)((int)0),OPT_SWITCH}, > -------------------------------------------------^ > {IMAPOPT_ALLOWNEWNEWS,"allownewnews",0,(union > config_value)((int)0),OPT_SWITCH}, > ---------------------------------------^ > > 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: > > ../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. > > 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 get similar errors when compiling libcyr_cfg.c as well, but in a > slightly different context, and doing the same deletion gets it to at > least compile. > This is because there is a cast to a union. Union casts are not ansi C compliant, but a gcc extension. Please see : http://gcc.gnu.org/onlinedocs/gcc/Cast-to-Union.html and http://groups.google.com/groups?q=union+cast+group:comp.lang.c.*&hl=en&lr=&ie=UTF-8&group=comp.lang.c.*&selm=21259%40mimsy.umd.edu&rnum=3 What I did is to remove the cast to a union type. This makes the syntax ansi c compliant. By default the compiler sets the rvalue to the first member of the union. And because the union is union config_value { const char *s; int i; int b; }; the compiler assigns the value to the char *s member of the union. For this reason every assignment to a string gets perfectly compiled. However, I had some warnings for the assignments of integers to a char *. In my case (Sun with Solaris 9) this creates no further problems, because the char *s and the integer members of the union share the same memory. But I am not sure what happens with different architectures that although the union members share the same memory, the byte alignment between the string and the integer may differ. > 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? > __atribute__ keyword handling is done at the configure script and for compilers that do not support this extension there is a #define statement. However, a '#include <config.h>' statement is missing from the lib/prot.h file and for this reason it does not build with other than gcc compilers. If you add it, then it is ok. Regards, Christos -- /** * Christos Soulios * Department of Informatics * University of Athens * e-mail : [EMAIL PROTECTED] */