Re: [Monotone-devel] compilation failure on Win32 MinGW

[Stephen Leake]

Markus Wanner <address@hidden> writes:

> Stephen Leake wrote:
>> compile on n.v.m Win32 MinGW is failing with:
>> 
>> ../monotone/botan/primes.cpp:608: warning: integer constant is too large for 
>> "long" type
>> 
>> These constants need a suffix 'LL' to be interpreted as type 'long long'.
>
> Yes, this is known an has been discussed with Jack. He didn't want that
> patched in upstream but instead requires an "-fpermissive" compiler flag.

What's the rationale for that? In general, the more compiler checking,
the better the code. 

That rationale should be documented in primes.cpp, so we don't have
this discussion again the next time someone tries to eliminate the
warning. 

On the other hand, "LL" isn't in the C++ 1998 standard; I'm not sure
about the C standards. This file is compiled with g++.

On the gripping hand, any compiler that supports 64 bit types needs to
support LL, so I don't see this as a portability issue. Then again,
compiler vendors sometimes do weird things :).

Is botan supposed to compile with anything other than Gnu compilers?

It may be that this should be "ULL", since it's unsigned.

> I'm pretty clearly against diverting from upstream, 

Agreed, but we should be clear on why upstream isn't adding "LL".

I committed this change over the weekend, because I wanted to fix
those warnings in nvm.resolve_conflicts. 

I'll take them back out for now.

> but this currently means compiling all of the 3rd party libraries
> with "-fpermissive".

Which means we're giving up a lot of compiler checks; that doesn't
seem like a good idea.

In general the autoconf stuff can handle per-file compiler options.
But that may be a pain to implement for this.

> I'm just wondering why this fails for MinGW. Is your gcc invoked with
> that flag or not?

It doesn't actually "fail", since it's just a warning. But in my
experience, C warnings are bad, and should be fixed. So I always
compile under Emacs, which highlights warnings in the compiler output.

It is compiled with -fpermissive. If I take that out, the warning
becomes an error.

With all the LLs in place, and removing -fpermissive, it compiles
without warning or error.

What is the compiler actually doing for these constants (without LL)?
The warning implies it is truncating them to 32 bits, which would be
really bad.

Do we have unit tests that verify the compiler is doing the right
thing?

>> See below for the patch for these changes. Any objection to committing
>> this?
>
> I've committed the changes to Makefile.am with minor adjustments and
> some comments on these exceptions. Thanks for your report and please
> test again.

It compiles fine now.

> All in all I'm really looking forward to nvm.stripped to get rid of
> these "custom build harness" issues. Do you mind test building that
> branch on MinGW?

Configure dies, with "error: Your lua library is not useable".

I don't have a MinGW Lua package installed. We'll need to update the
MinGW installation instructions on the Wiki. But apparently the Wiki
is moribund at the moment?

I'll have to get my MinGW buildbot back on line; the video output
died, so I need to get a new computer.

-- 
-- Stephe