Re: Tru64 and 2.2 problems - cast-to-union
Just to add an oppinion. I do not and cannot accept the point GCC is standard - yield to it. GCC is yet another C language standard and should be treated that way. So far we have KR C, ANSI C, ISO C and GNU C. I would welcome emerging of ONE C standard, but then we should all push for it. Why would GCC be more expressive that ANSI C (which is mostly supported as a standard, I believe)? Is ANSI C unportable to GNU C? I 100% agree with you here! I love GCC, but I like to use other compilers too, and as it turns out, I prefer to program in such a way that my code will compile on *any* C compiler if at all possible. I don't understand the reasoning behind the just use gcc group when there are many better reasons to use a native compiler designed for the platform to be used. It is not just whether native compiler is better that Global GNU CC. It is (for me) a point of expressiveness. What is it that you can express with GCC constructs, that cannot be expressed elegantly with ANSI C? If there is something like that, then propose it as a change in standard, rather than being autistic and saying it's either GNU way or the highway (deliberate exageration in this case). By the way, you are sending your responses directly to me... why not CC the mailing list too? I think it is worthy of discussion! Sorry. Corrected. Nix.
Re: Tru64 and 2.2 problems
Even though your suggestions were good, they weren't applicable to this
particular issue. In fact, running the find command to find all the
source files with indented directives only showed up a couple lines as
follows (using a slightly different command than you supplied):
% find . -name '*.[ch]' | xargs egrep '^[: :]+#'
./sieve/addr-lex.c: #pragma warn -rch
./sieve/addr-lex.c: #pragma warn -use
./sieve/sieve-lex.c: #pragma warn -rch
./sieve/sieve-lex.c: #pragma warn -use
Even though it has no bearing on the problem I was having, it is worth
fixing those few lines (by removing the single space before the #pragma)
just to increase the portability of the source code.
Scott
--On Wednesday, July 23, 2003 7:24 AM +0200 Nikola Milutinovic
[EMAIL PROTECTED] wrote:
First thing first, to quote your message. Have you cleaned up the
source from indented CPP directives?
GCC (and possibly other C compilers) support indentation of CPP
directives (#define, #include, etc.). CC doesn't deal with this and
ignores such lines. There is no public standard that allows it - the most
that is allowed is to indent the directive, but to keep # in column 1.
So, this is what GNU allows:
# ifdef HAS_GETADDRINF
#define OK
#include sys/socket.h
# else
#include sys/sock5.h
# endif
DEC CC would go no further than this:
# ifdef HAS_GETADDRINF
#define OK
#include sys/socket.h
# else
#include sys/sock5.h
# endif
So, the first thing to do is clean up all *.c, *.h and configure*
files that you can find. I use a script:
find . \( -name configure* -o -name *.c -o -name *.h \) -exec grep
-E ^( |\t)( |\t)*#(i|d|e|p|u) {} \; -print
(I have placed \t for TABs, in my script they are really TABs - cant
display TABs in MS Outlook Express).
Then look at what's reported and edit all those files. Or write another
script to do the change - sed comes to mind. Or Perl.
When you have cleaned up, then you can start tracking errors and bugs.
Nix.
--
+---+
Scott W. Adkinshttp://www.cns.ohiou.edu/~sadkins/
UNIX Systems Engineer mailto:[EMAIL PROTECTED]
ICQ 7626282 Work (740)593-9478 Fax (740)593-1944
+---+
PGP Public Key available at http://www.cns.ohiou.edu/~sadkins/pgp/
pgp0.pgp
Description: PGP signature
Re: Tru64 and 2.2 problems - cast-to-union
--On Wednesday, July 23, 2003 11:23 AM +0100 Christos Soulios [EMAIL PROTECTED] wrote: 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. [text deleted about (union cyrus_config_value) type cast stuff] This is because there is a cast to a union. Union casts are not ansi C compliant, but a gcc extension. What I did is to remove the cast to a union type. This makes the syntax ansi c compliant. Right, this is what I did as well... basically, I was left with the int and const char * type casts, which naturally generated warnings. 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. Yes, this is a concern for me... I am not exactly sure how this will be stored in Tru64. We are talking about a char * and an int stored in the same location. I have always known them to consume 4 bytes of memory, but my manager isn't so sure, thinking that maybe it is 8 bytes of memory these days for more efficient storage. The little-endian and big-endian issue may definitely be a problem, and I don't know if that will affect us. The only thing I can really do is maybe write a little test program that does what the Cyrus code was trying to do and see how it is stored. I looked at the command line options of CC to see if I could loosen up the ANSI compliant restrictions a bit and make it work... there is an option called -noansi_alias that does that, but it didn't help. I then found some documentation where it is explicitely stated that Tru64 CC does not support the union-to-cast extension and has no intension of doing so in the future. So, there you have it. Isn't there a more portable way of doing this? Requiring GCC for the compilation of Cyrus is a bit too strict, in my opinion. Rob sent another message out asking me why I just don't use GCC anyways, because it would be simpler than them rewriting the code to make it more portable. I just don't agree with that... in fact, the Tru64 CC compile is highly optimized for the platform, takes advantage of all the pipelining and special ways that the architecture is designed to execute code. Sure, Compaq supplied a bunch of code to GCC, but it is nowhere near what is already in the CC compiler, and on top of that, the engineers there have stated that they are constantly comparing CC to GCC to see how it compares, and CC always blows away GCC with regards to performance. Why switch to GCC and lose any performance gains we would have had just to support a GCC specific extension which is a bit controversial in nature to begin with? I would be in favor of simply modifying the imapopts structure so that we can make it work without portability problems... something I may look at down the road... whether CMU is interested that is another question. Scott -- +---+ Scott W. Adkinshttp://www.cns.ohiou.edu/~sadkins/ UNIX Systems Engineer mailto:[EMAIL PROTECTED] ICQ 7626282 Work (740)593-9478 Fax (740)593-1944 +---+ PGP Public Key available at http://www.cns.ohiou.edu/~sadkins/pgp/ pgp0.pgp Description: PGP signature
Re: Tru64 and 2.2 problems - __attribute__ in prot.h
--On Wednesday, July 23, 2003 11:23 AM +0100 Christos Soulios [EMAIL PROTECTED] wrote: 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. You are absolutely correct, and this indeed fixed the problem elegantly. Rob, can you throw a #include config.h at the top of prot.h in CVS, or do you need a patch given to you? Scott -- +---+ Scott W. Adkinshttp://www.cns.ohiou.edu/~sadkins/ UNIX Systems Engineer mailto:[EMAIL PROTECTED] ICQ 7626282 Work (740)593-9478 Fax (740)593-1944 +---+ PGP Public Key available at http://www.cns.ohiou.edu/~sadkins/pgp/ pgp0.pgp Description: PGP signature
Re: Tru64 and 2.2 problems - getaddrinfo
--On Tuesday, July 22, 2003 5:08 PM -0400 Rob Siemborski [EMAIL PROTECTED] wrote: 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. As you are already aware, this has been opened in buzilla and a suggested patch has been provided. I can confirm that the patch works great and I recommend it to be used... getaddrinfo() is now being properly detected in Tru64 and gets used. I still run into a problem with gai.h where getnameinfo() for Tru64 is different than what the prototype in that header file describes... as a result, the compilation process halts with a fatal error. I wrapped the getnameinfo() prototypes with #ifndef HAVE_GETNAMEINFO/#endif, and wrapped the getaddrinfo() and freeaddrinfo() prototypes with a HAVE_GETADDRINFO like block. I will provide that in a patch in the next mailing. Scott -- +---+ Scott W. Adkinshttp://www.cns.ohiou.edu/~sadkins/ UNIX Systems Engineer mailto:[EMAIL PROTECTED] ICQ 7626282 Work (740)593-9478 Fax (740)593-1944 +---+ PGP Public Key available at http://www.cns.ohiou.edu/~sadkins/pgp/ pgp0.pgp Description: PGP signature
Re: Tru64 and 2.2 problems
Scott Adkins wrote:
Even though your suggestions were good, they weren't applicable to this
particular issue. In fact, running the find command to find all the
source files with indented directives only showed up a couple lines as
follows (using a slightly different command than you supplied):
% find . -name '*.[ch]' | xargs egrep '^[: :]+#'
./sieve/addr-lex.c: #pragma warn -rch
./sieve/addr-lex.c: #pragma warn -use
./sieve/sieve-lex.c: #pragma warn -rch
./sieve/sieve-lex.c: #pragma warn -use
Even though it has no bearing on the problem I was having, it is worth
fixing those few lines (by removing the single space before the #pragma)
just to increase the portability of the source code.
These files are generated by flex, and I don't think we want to get into
massaging its output. Are you saying that the leading space is illegal,
or that your compiler just doesn't like it?
Scott
--On Wednesday, July 23, 2003 7:24 AM +0200 Nikola Milutinovic
[EMAIL PROTECTED] wrote:
First thing first, to quote your message. Have you cleaned up the
source from indented CPP directives?
GCC (and possibly other C compilers) support indentation of CPP
directives (#define, #include, etc.). CC doesn't deal with this and
ignores such lines. There is no public standard that allows it - the most
that is allowed is to indent the directive, but to keep # in column 1.
So, this is what GNU allows:
# ifdef HAS_GETADDRINF
#define OK
#include sys/socket.h
# else
#include sys/sock5.h
# endif
DEC CC would go no further than this:
# ifdef HAS_GETADDRINF
#define OK
#include sys/socket.h
# else
#include sys/sock5.h
# endif
So, the first thing to do is clean up all *.c, *.h and configure*
files that you can find. I use a script:
find . \( -name configure* -o -name *.c -o -name *.h \) -exec grep
-E ^( |\t)( |\t)*#(i|d|e|p|u) {} \; -print
(I have placed \t for TABs, in my script they are really TABs - cant
display TABs in MS Outlook Express).
Then look at what's reported and edit all those files. Or write another
script to do the change - sed comes to mind. Or Perl.
When you have cleaned up, then you can start tracking errors and bugs.
Nix.
--
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
716-662-8973 x26 Orchard Park, NY 14127
--PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
Re: Tru64 and 2.2 problems
--On Thursday, July 24, 2003 2:56 PM -0400 Ken Murchison [EMAIL PROTECTED] wrote: Scott Adkins wrote: Even though your suggestions were good, they weren't applicable to this particular issue. In fact, running the find command to find all the source files with indented directives only showed up a couple lines as follows (using a slightly different command than you supplied): % find . -name '*.[ch]' | xargs egrep '^[: :]+#' ./sieve/addr-lex.c: #pragma warn -rch ./sieve/addr-lex.c: #pragma warn -use ./sieve/sieve-lex.c: #pragma warn -rch ./sieve/sieve-lex.c: #pragma warn -use Even though it has no bearing on the problem I was having, it is worth fixing those few lines (by removing the single space before the #pragma) just to increase the portability of the source code. These files are generated by flex, and I don't think we want to get into massaging its output. Are you saying that the leading space is illegal, or that your compiler just doesn't like it? Well, I looked at those files and thought they would be generated by flex, but when I untarred the distribution, they were already there. Are they recreated on the fly, or are the ones provided in the distribution used? As far as the leading space goes, it works on the Tru64 compiler, but I *have* used compilers where the leading space was not permitted. It is actually a CPP problem, not a compiler problem. With CPP's that don't like it, the compile will fail and not just issue warnings. Keep in mind that the only directives in the whole source of Cyrus that has leading spaces are the 4 lines in the above 2 files. The fixes are purely for portability reasons. If you want indentation, then you put the spaces between the # and the pragma, as long as the # is the first character of the line. Anyways, obviously minor. Scott -- +---+ Scott W. Adkinshttp://www.cns.ohiou.edu/~sadkins/ UNIX Systems Engineer mailto:[EMAIL PROTECTED] ICQ 7626282 Work (740)593-9478 Fax (740)593-1944 +---+ PGP Public Key available at http://www.cns.ohiou.edu/~sadkins/pgp/ pgp0.pgp Description: PGP signature
Re: Tru64 and 2.2 problems
On Thu, 24 Jul 2003, Scott Adkins wrote: % find . -name '*.[ch]' | xargs egrep '^[: :]+#' ./sieve/addr-lex.c: #pragma warn -rch ./sieve/addr-lex.c: #pragma warn -use ./sieve/sieve-lex.c: #pragma warn -rch ./sieve/sieve-lex.c: #pragma warn -use Even though it has no bearing on the problem I was having, it is worth fixing those few lines (by removing the single space before the #pragma) just to increase the portability of the source code. Sadly, these lines are generated by lex, and are somewhat (though not totally) out of our control to fix. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Tru64 and 2.2 problems
On Thu, 24 Jul 2003, Scott Adkins wrote: Well, I looked at those files and thought they would be generated by flex, but when I untarred the distribution, they were already there. Are they recreated on the fly, or are the ones provided in the distribution used? They'll be recreated if they don't exist, but you need to have flex to recreate them, which is why they are included. As far as the leading space goes, it works on the Tru64 compiler, but I *have* used compilers where the leading space was not permitted. It is actually a CPP problem, not a compiler problem. With CPP's that don't like it, the compile will fail and not just issue warnings. I agree, if I controlled flex, I'd fix this, since the leading space isn't really portable. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Tru64 and 2.2 problems
Scott Adkins wrote: --On Thursday, July 24, 2003 2:56 PM -0400 Ken Murchison [EMAIL PROTECTED] wrote: Scott Adkins wrote: Even though your suggestions were good, they weren't applicable to this particular issue. In fact, running the find command to find all the source files with indented directives only showed up a couple lines as follows (using a slightly different command than you supplied): % find . -name '*.[ch]' | xargs egrep '^[: :]+#' ./sieve/addr-lex.c: #pragma warn -rch ./sieve/addr-lex.c: #pragma warn -use ./sieve/sieve-lex.c: #pragma warn -rch ./sieve/sieve-lex.c: #pragma warn -use Even though it has no bearing on the problem I was having, it is worth fixing those few lines (by removing the single space before the #pragma) just to increase the portability of the source code. These files are generated by flex, and I don't think we want to get into massaging its output. Are you saying that the leading space is illegal, or that your compiler just doesn't like it? Well, I looked at those files and thought they would be generated by flex, but when I untarred the distribution, they were already there. Are they recreated on the fly, or are the ones provided in the distribution used? They are included in the distribution so that you don't need flex and yacc. If you use CVS, then these will be built on the fly. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
Re: Tru64 and 2.2 problems - cast-to-union
Scott Adkins wrote: Yes, this is a concern for me... I am not exactly sure how this will be stored in Tru64. We are talking about a char * and an int stored in the same location. I have always known them to consume 4 bytes of memory, but my manager isn't so sure, thinking that maybe it is 8 bytes of memory these days for more efficient storage. The little-endian and big-endian alpha is 64-bit. It conforms to the LP64 standard (long/pointers are 64 bits). Thus under normal circumstances pointers and longs (long int) are 64 bits == 8 bytes. A union of char * and int will be 8 bytes long. For completeness I mention the compiler and linker flags -taso, -xtaso, and -xtaso_short, which can be used to force the compiler/linker to make virtual addresses fit within 32-bits, and also make pointers 32-bits long, but unless you're trying to compile horribly unportable code you should avoid these. Isn't there a more portable way of doing this? Requiring GCC for the compilation of Cyrus is a bit too strict, in my opinion. Rob sent another message out asking me why I just don't use GCC anyways, because it would be simpler than them rewriting the code to make it more portable. I just don't agree with that... in fact, the Tru64 CC compile is highly optimized for the platform, takes advantage of all the pipelining and special ways that the architecture is designed to execute code. Sure, Compaq supplied a bunch of code to GCC, but it is nowhere near what is already in the CC compiler, and on top of that, the engineers there have stated that they are constantly comparing CC to GCC to see how it compares, and CC always blows away GCC with regards to performance. Why switch to GCC and lose any performance gains we would have had just to support a GCC specific extension which is a bit controversial in nature to begin with? also, if the DECC compiler can compile something, because of its strictness the chances are very good that other compilers will too. That is, getting rid of errors that DECC brings to light makes the code cleaner... Rob Urban
Re: Tru64 and 2.2 problems
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=enlr=ie=UTF-8group=comp.lang.c.*selm=21259%40mimsy.umd.edurnum=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]
*/
Re: Tru64 and 2.2 problems
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
Re: Tru64 and 2.2 problems
On Tue, 22 Jul 2003, Rob Siemborski wrote: I thought you said it wasn't running at all? Sorry, I missed the part about getting it working using LD_LIBRARY_PATH. OOC, how do other executables that need libraries from multiple directories work on Tru64? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Tru64 and 2.2 problems
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
Re: Tru64 and 2.2 problems
On Wed, 23 Jul 2003, Robert Urban wrote: 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... If you can suggest changes to Cyrus such that configure does the right thing, I'd appreciate it. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
