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

[Markus Wanner]

Hello Stephen,

Stephen Leake wrote:
> compile on n.v.m Win32 MinGW is failing with:
> 
> ../monotone/botan/es_dev.cpp:7:24: sys/select.h: No such file or directory

Hm.. thanks for that report. Must have to do with our self-made build
harness for botan and the upgrade to botan 1.7.12 (which already seems
old by now).

> The problem is in Makefile.am BOTAN_SOURCES; previously, 'es_dev.cpp'
> was not included there; it was added if needed in
> lib3rdparty_a_SOURCES by an 'if WIN32_PLATFORM' conditional.
> 
> That conditional is still there, and does the same thing.
> 
> So I think we just need to delete 'es_dev.cpp' from BOTAN_SOURCES.

That seems correct, thanks.

> Hmm. That almost works; now I get the same error in 'es_egd.cpp'. This
> was previously not compiled on Win32, but also not on other OS as
> well, apparently. It could be added to the same 'if WIN32_PLATFORM'
> conditional. That gives no errors on Win32 (obviously).

According to the botan module build information, es_egd is only supposed
to be built for unix systems. That didn't get clear from your
description, but you did keep es_egd.cpp for Unixen in your patch. So did I.

> Then I get:
> 
> ../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.

I'm pretty clearly against diverting from upstream, but this currently
means compiling all of the 3rd party libraries with "-fpermissive".

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

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

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?

Regards

Markus Wanner