Re: [Monotone-devel] compilation failure on Win32 MinGW
Hi, Stephen Leake wrote: > There's no search function at > http://lists.randombit.net/pipermail/botan-devel/, so that's rather difficult. Oh, hm.. Jack? > Then I suggest we put a comment in the code at that point saying we > are ignoring the warning, so this doesn't come up again. That would only lead to tedious merge failures for upgrades. Better strip that 3rd party library... > I guess we assume botan has its own test suite; those of us who are > paranoid should run it in addition to the mtn test suite :). That's close to impossible to do for the integrated botan. You'd have to "port" the test suite. Again, strip it! > Well, we could add a "future process" section to the wiki. But this is > moot, since the wiki is currently not editable. Good point. What's up with the wiki? Let's start another thread for that question, though... Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] compilation failure on Win32 MinGW
Markus Wanner <[EMAIL PROTECTED]> writes: > 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. There's no search function at http://lists.randombit.net/pipermail/botan-devel/, so that's rather difficult. >> 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. Sorry. My personal policy is that warnings must be treated as failures. It has saved me many headaches in the past. > The warning is there on gcc on all platforms and should be ignored. Then I suggest we put a comment in the code at that point saying we are ignoring the warning, so this doesn't come up again. >> 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. The problem with C compiler warnings is distinguishing the merely annoying ones from the important ones. It's easy enough to eliminate this warning; why make people wonder whether it's important or not? >> 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 ;-) botan is a core component of monotone. If it doesn't work, monotone doesn't work. I don't trust _any_ compiler; that's what unit tests are for. I guess we assume botan has its own test suite; those of us who are paranoid should run it in addition to the mtn test suite :). >>> 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. Well, we could add a "future process" section to the wiki. But this is moot, since the wiki is currently not editable. Perhaps the INSTALL doc in nvm.stripped would be a better place to document the MinGW build process. or INSTALL.MinGW. > Do you have a lua library at all? Only the one included in monotone. I'll try downloading the upstream source and see what happens when I try to build it under MinGW. > Maybe it should say: not found, instead of not usable? I think it's clear enough: I know I don't have a lua lib for it to find. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] compilation failure on Win32 MinGW
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 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] compilation failure on Win32 MinGW
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
Re: [Monotone-devel] compilation failure on Win32 MinGW
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 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] compilation failure on Win32 MinGW
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
followed by more errors in the same file.
MinGW doesn't have 'sys/select.h'.
Previously, this file was not compiled on Win32.
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.
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).
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'.
Then everything compiles, and passes all tests (except --no-workspace;
separate email for that).
See below for the patch for these changes. Any objection to committing
this?
--
-- Stephe
#
# old_revision [fd7cce0c58cb2c1e01c041539eba882abfc42b10]
#
# patch "Makefile.am"
# from [32daafd4f09fdd8cee6b82c58518f5d9665bf904]
#to [99d211f3a07989d2ae8b6fa5e0a0a9b3f2704e11]
#
# patch "botan/primes.cpp"
# from [d3f6a25e1bb8734a71e24c6df0a35e7d66ddce55]
#to [c5d73dc8e6ad1a78f64b795008a7d9540c0eb3ef]
#
*** Makefile.am 32daafd4f09fdd8cee6b82c58518f5d9665bf904
--- Makefile.am 99d211f3a07989d2ae8b6fa5e0a0a9b3f2704e11
*** BOTAN_SOURCES =
\
*** 125,132
botan/dsa_gen.cpp botan/eax.cpp botan/ecb.cpp botan/eme1.cpp\
botan/eme_pkcs.cpp botan/emsa1.cpp botan/emsa2.cpp \
botan/emsa3.cpp botan/emsa4.cpp botan/emsa_raw.cpp \
! botan/eng_base.cpp botan/engine.cpp botan/es_dev.cpp\
! botan/es_egd.cpp botan/exceptn.cpp botan/filter.cpp \
botan/filters.cpp botan/get_algo.cpp botan/get_enc.cpp \
botan/get_pbe.cpp botan/hash_id.cpp botan/hex.cpp \
botan/hmac.cpp botan/if_algo.cpp botan/init_def.cpp \
--- 125,132
botan/dsa_gen.cpp botan/eax.cpp botan/ecb.cpp botan/eme1.cpp\
botan/eme_pkcs.cpp botan/emsa1.cpp botan/emsa2.cpp \
botan/emsa3.cpp botan/emsa4.cpp botan/emsa_raw.cpp \
! botan/eng_base.cpp botan/engine.cpp \
! botan/exceptn.cpp botan/filter.cpp \
botan/filters.cpp botan/get_algo.cpp botan/get_enc.cpp \
botan/get_pbe.cpp botan/hash_id.cpp botan/hex.cpp \
botan/hmac.cpp botan/if_algo.cpp botan/init_def.cpp \
*** else
*** 451,456
--- 451,457
libplatform_a_SOURCES += $(UNIX_PLATFORM_SOURCES)
mtn_SOURCES += unix/main.cc
lib3rdparty_a_SOURCES += botan/es_dev.cpp
+ lib3rdparty_a_SOURCES += botan/es_egd.cpp
tester_SOURCES += unix/tester-plaf.cc
check_net_SOURCES = unix/tester-check-net.c
endif
*** botan/primes.cppd3f6a25e1bb8734a71e24c6df0a35e7d66ddce55
--- botan/primes.cppc5d73dc8e6ad1a78f64b795008a7d9540c0eb3ef
*** const u64bit PRIME_PRODUCTS[PRIME_PRODUC
*** 605,674
65437, 65447, 65449, 65479, 65497, 65519, 65521, 0 };
const u64bit PRIME_PRODUCTS[PRIME_PRODUCTS_TABLE_SIZE] = {
! 0xFF658BDE2F2A43DF, 0xFEEB94CD535119ED, 0xFA921839EC24DDD5,
0xFDDA766C77E1E605,
! 0xFF3024B0EB4EE333, 0xFEEE350BBC92F4DF, 0xFFC724B7D011D01B,
0xFEED34B826C33B05,
! 0xFE69D8DE3F85C6E3, 0xFE3B48909250918F, 0xFF8EC0CE9C632429,
0xFFD92A5C78226D6B,
! 0xFFB4BFB0C65133CF, 0xFE77113704902C57, 0xFF8A21D222EA81FD,
0xFEDA1299661CF5AB,
! 0xFF4CE86187737D0D, 0xFFD26443A07F519D, 0xFFA817B7191D7967,
0xFF00EDC142868873,
! 0xFFB9C6D7F7A239B7, 0xFFE76D3481E98E39, 0xFF76D5432584120D,
0xFFAA499F071EC705,
! 0xFEB5198F05722E59, 0xFF7E0431CA41107F, 0xFFCFD52FEDDC928F,
0xFE0EA42537BC6ABF,
! 0xFF64937896876925, 0xFC6FC87E811607D3, 0xFFBF600E6CDD0F4F,
0xFF022700FE658243,
! 0xFF2E21166779D6B9, 0xFFC224624C665C33, 0xFF1372F41FF177AD,
0xFF31E57E972D0C13,
! 0xFFA891F866404D23, 0xFF7BF13EF716E9A3, 0xFE51CAFD9466E733,
0xFDA1CF55F6D6336F,
! 0xFFAF6C040ED0950F, 0xFFAA1725F40BA269, 0xFEC593BC3570BEEB,
0xFEE05B35B426F413,
! 0xFFCA5209A08890F9, 0xFFED8AF70EB0CC89, 0xFF3F98E3E27860A5,
0xFF92FECD017FF9F7,
! 0xFEFA655B2609018F, 0xFFFC51D15AAC7B77, 0xFEF5007E71420DB1,
0xFFEC4784141332D1,
! 0xFE8384ED4E1D21CD, 0xFFD3FF614D3ECC47, 0xFFDE5166FD540313,
0xFF5320ECED04B26F,
! 0xFF223980F122FF75, 0xFF19C1F27CB1B4A5, 0xFF0F1DFC9DA9523B,
0xFF82DE7B387F5427,
! 0xFF9A026BA87314E3, 0xFFAC7FF3ACE64E77, 0xFF808EB2FD5873C3,
0xFE983ED5BB
Re: [Monotone-devel] compilation failure on Win32 MinGW
Markus Wanner <[EMAIL PROTECTED]> writes: > Hi, > > Stephen Leake wrote: >> Stephen Leake <[EMAIL PROTECTED]> writes: >> >>> compile on Win32 MinGW is failing with: >> >> in branch net.venge.monotone >> >>> make[3]: *** No rule to make target `../monotone/botan/big_base.cpp', >>> needed by `botan/lib3rdparty_a-big_base.o'. Stop. > > Hm.. did you run 'make distclean' and probably re-run the autoconf > toolchain? Sorry, I forgot 'autoreconf -i'. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] compilation failure on Win32 MinGW
Hi, Stephen Leake wrote: > Stephen Leake <[EMAIL PROTECTED]> writes: > >> compile on Win32 MinGW is failing with: > > in branch net.venge.monotone > >> make[3]: *** No rule to make target `../monotone/botan/big_base.cpp', needed >> by `botan/lib3rdparty_a-big_base.o'. Stop. Hm.. did you run 'make distclean' and probably re-run the autoconf toolchain? I've upgraded the included botan version which carried some renames and such. But I didn't test on Win32. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] compilation failure on Win32 MinGW
Stephen Leake <[EMAIL PROTECTED]> writes: > compile on Win32 MinGW is failing with: in branch net.venge.monotone > make[3]: *** No rule to make target `../monotone/botan/big_base.cpp', needed > by `botan/lib3rdparty_a-big_base.o'. Stop. > > Is that a generated file, or did it just not get checked in? > > -- > -- Stephe > > > ___ > Monotone-devel mailing list > Monotone-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/monotone-devel > -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] compilation failure on Win32 MinGW
compile on Win32 MinGW is failing with: make[3]: *** No rule to make target `../monotone/botan/big_base.cpp', needed by `botan/lib3rdparty_a-big_base.o'. Stop. Is that a generated file, or did it just not get checked in? -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
