Markus Wanner <[EMAIL PROTECTED]> 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 _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
