[Top][All Lists]
[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