monotone-devel
[Top][All Lists]
Advanced

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

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


From: Markus Wanner
Subject: Re: [Monotone-devel] compilation failure on Win32 MinGW
Date: Tue, 28 Oct 2008 10:06:55 +0100
User-agent: Thunderbird 2.0.0.16 (X11/20080916)

Hi,

Stephen Leake wrote:
> Is botan supposed to compile with anything other than Gnu compilers?

Yes.

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

Please check the botan-devel archive.

> 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.

Good.

>> 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.

Agreed. nvm.stripped helps that. AFAICT Jack thinks of it as gcc being
overly pedantic. In that case, I absolutely agree with him.

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

Yes, having done the recent integrated-botan upgrades, I strongly
recommend against such a thing.

Botan itself doesn't use autoconf.

> 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.

Ah! So, please be more specific. The warning is there on gcc on all
platforms and should be ignored.

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

Sure.

> 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.

It doesn't truncate them, it's just an annoying and pedantic warning,
AFAICT.

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

No, why should we? It's a botan thing. Please concentrate on monotone ;-)

>> 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.

Cool, thanks for testing.

>> 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?

nvm.stripped hasn't landed, yet, so I don't think updating the Wiki is
the first thing to do. We (you?) first need to figure out how to compile
nvm.stripped on MinGW, then we can document.

Do you have a lua library at all? Maybe it should say: not found,
instead of not usable? The m4 scripts aren't overly clever, yet. I was
hoping some m4 wizard could pick up and help, because I'm not
particularly found in m4.

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

Having a MinGW buildbot would certainly be cool.

Regards

Markus Wanner




reply via email to

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