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.
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
--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
--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,
--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
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):
--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
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
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
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
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
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
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
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
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
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
16 matches
Mail list logo
