> 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 K&R C, ANSI C, ISO C and GNU C. I would welcome emerging of
>> ONE C standard, but then we should all p
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
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
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
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 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
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 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 ge
--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 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 (unio
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]
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 g
On Wed, 23 Jul 2003, Robert Urban wrote:
> Tru64 does indeed have a getaddrinfo, it even has two. You must
>
> #include
>
> 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
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 h
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
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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, t
Okay, I have enough problems now to post something.
We are running on a Tru64 5.1a cluster (2 machines). Compiling 2.2.1 has
not been a pleasant prospect. We are using Tru64's cc compiler, and are
not permitted to use the gcc compiler.
First thing is first, we are using SASL-2.15.1 and BerkeleyD
17 matches
Mail list logo
