bug-mailutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: (no subject)


From: Sam Roberts
Subject: Re: (no subject)
Date: Sun, 24 Feb 2002 15:04:05 -0500
User-agent: Mutt/1.3.16i

Quoting Steven Michael ROBBINS <address@hidden>, who wrote:
> On Thu, Feb 14, 2002 at 11:46:09AM -0500, Sam Roberts wrote:
> > Hi Steven,
> > 
> > Sorry for the delay.
> > 
> > Ok, I've a Tru64 machine, but other than building our software on it,
> > I don't have any experience with porting to it.
> > 
> > I'm trying to reproduce this, and I'm having some trouble, and I don't
> > have that much time.
> > 
> > Some questions:
> > 
> > - what are you building? Did you get a release package that already
> > had the configure script built, or did you do the autogen.sh yourself?
> 
> The latter: I'm working with gnu-mailutils from CVS at cvs.gnu.org.
>  
> > - can you send me your package?
> 
> I could.  But it is just the check-out from CVS with the diff
> I had sent.  I'll get back to you later about this.

I don't have the autotools on the Tru64 box, I did the make release
on a linux box, and ftped the release over to Tru64. I wouldn't
work at all without GNU make (Jeff, I agree it shouldn't be like
this, I'll send you and Steven the output if I can't figure out
what construct this make is having trouble with).

> > - if you did the autogen.sh, what versions of autoconf and the rest are
> > you using?
> 
> I was using autoconf 2.13, automake 1.4d, and libtool 1.2.something.
> Yesterday I updated the latter two to automake 1.5 and libtool 1.4.2.

I'll see what I'm using.

> > - how do you call configure? do you use GNU make, or the vendors make?
> > Are the GNU tools installed?
> 
> I normally call "./configure --prefix=/labs/cgm".  The GNU tools are
> installed, including GNU make, and GCC 3.0.3.
> 
> I normally invoke configure and let it work out which compiler to use,
> which is normally gcc.  I don't recall why I was using the vendor compiler,
> to be honest.  I must have set CC=cc before calling configure.
> 
> I tried building with GCC last night and ran into a completely
> different problem: /usr/include/mesg.h defines a structure named
> _message, and so do two of the mailutils headers.  The former appears
> to be related to message catalogs for localization.  I don't know
> why it gets included when building with GCC.  Maybe that's why I
> switched to the vendor compiler ...

I'll try both again.

> So I rebuilt it just now using vendor cc, and it built (with my patch).
>  
> > I had to modify my PATH to ensure that the vendors compiler was found,
> > and not gcc.
> 
> It is easier to just do "CC=/usr/bin/cc ./configure ..."!

Yes, I guess it would be!

> 
> > However, I still have to use GNU make.
> 
> OK, but that is not relevant to compiler warnings ;-)

No, but it was preventing cc from being called at all!

> > I'm also getting
> > lots of warnings, and finally errors. But... I don't see PROTOTYPES
> > defined by anything, and I don't see the presence of the prototypes
> > causing any problems.
> 
> As I recall, it was the *absence* of prototypes causing the problem ;-)
> 
> I believe that the vendor cc does not define __STDC__, but it does
> support prototypes.  The symbol __STDC__ has to do with the presence of
> standard C library headers, which is orthogonal to whether the compiler
> has any given feature.

Hmmm, I'm not sure I saw this. The built got a dozen files in before
choking (with cc) on what looked like prototype unrelated problems.

> The autoconf manual has this to say about AC_C_PROTOTYPES:
> 
>  - Macro: AC_C_PROTOTYPES
>      Check to see if function prototypes are understood by the
>      compiler.  If so, define `PROTOTYPES'. 
> 
> That is why I changed all the prototype conditions from #if __STDC__
> to #if PROTOTYPES.
> 
> (Oh, and PROTOTYPES is defined in config.h)

Ok, I see now. That seems pretty reasonable.

> I want to use the imap daemon.  However, the build spews lots of warnings
> about pointer/integer conversion (this is a 64 bit machine) and I'm 
> reluctant to replace so vital a daemon until I'm sure it doesn't have
> "64 bit issues".

Ok, I'll try again, and I'll take a look at the conversion warning
if I have time.

Sam

-- 
Sam Roberts <address@hidden> (Vivez sans temps mort!)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]