By default enum is a signed integer. It creates signed/unsigned mismatch mismatch if used in expression like this: return ((nStatus & BLOCK_VALID_MASK) >= nUpTo); --(Main.h - line 737)
To avoid this condition making enum smallest unsigned type to hold all values 0 - 96 which is unsigned char. For more info please see this: http://msdn.microsoft.com/en-us/library/y92ktdf2.aspx
Sounds like a compiler bug. I'm surprised Bitcoin Core builds in MSVC at all.
Looks like a legitimate "doesnt compile" with old gcc. @theuni should Travis not also run with such an old gcc to catch this?
It builds quite well. I have list of warning to cleanup (4018;4101;4146;4999;4244;4267;4345;4503;4717;4786;4800;4804;4805;4996;) but otherwise it is fine.
@TheBlueMatt I'm all for adding different compilers in order to maintain portability (cleaning up the warnings from clang -Weverything could keep someone busy for months), but I don't see much utility in adding outdated compilers just so that we can see if we hit their bugs. If we're going to add different compiler configs, imo clang/msvc/icc would be more real-world useful.
Unless, of course, there's a legitimate use for testing against broken/old compilers. LTS ppa toolchains, for example.
@theuni I was under the impression the compiler on pull-tester's windows build was the same as the Ubuntu LTS's max mingw version?
I am actually quite surprised you don’t target MSVC tool chain. There are a lot mere developers working with Visual Studio than with gcc in Windows. Cost of entry (in terms of learning and setup) is much smaller with VS IDE as opposed to all these cross compiler and since Windows still predominant OS on desktop you do the math. If wider adoption is a goal code should be buildable on VS so more people could jump in.
@TheBlueMatt Not sure about pull-tester. Travis uses the same as Gitian. @ENikS we don't target any toolchains, but we do test and support-ish some. Due to the nature of Bitcoin, most devs work in Linux, some in OSX, some in the BSDs, and few in Windows. Official builds must be created using an entirely free/open stack, including the toolchain. mingw is much easier to automate for c-i and deployments, so it's the obvious choice for us.
However, there's no reason why the code shouldn't build under MSVC. Any build failure (assuming it's caused by non-conformant code as opposed to a MSVC quirk) is a bug and should be fixed.
@theuni pull-tester uses the same that gitian used to, I suppose it was updated?
If someone walks me through your automated build process perhaps I could help to set something similar for the msvc free tool set. Something like VS Express of MSBuild with SDK. I don't have much time, have to work for living but this would be worth some effort.
I don't think the current build system (autotools + make) can use the MSVC compiler. What projects usually do is to have a parallel build system specifically for MSVC, i.e. by checking in a solution file. But it will be a maintenance burden to make sure that doesn't get out of sync when files are moved around. Maybe it would be possible to generate a MSVC solution file from the current build system somehow.
I also know it's possible to call the MSVC compiler from WINE, so scripting to run it automatically on a linux host would be possible, which can make it a little easier for the other developers without windows to check it as well.
Seems like quite some work, but if you think it's worth the trouble, why not.
You saying this territory would not be worth exploring? I know there are interest in Windows community but last two attempts at participation died because of luck of support (may be it is not dead but it has no updates, and I am not sure if either Claire DuSoleil or bc4-old-c-coder even asked for it). I think core should be available on windows as well as any other OS with native support and willing to help. I don't have much time because I have to work at my paying job so I can not volunteer for the entire effort but if someone would help with the environment I would provide msvc specific configuration.
Code in present form builds and runs in Visual Studio so it would require no changes whatsoever.
@ENikS if you mean how to build with gitian, see https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md
@ENikS I'm afraid you're on your own for that. We use mingw precisely because it's free to acquire and easy to automate. You won't be able to achieve the same thing with MSVC+Windows because you can't simply spin up an environment without licensing. You'll have to either accept that and cope as well as possible, or get creative as @laanwj suggested with something like Wine+Linux.
@ENikS fwiw, I think a much more realistic next step would be to get a mingw environment up and running under Windows. That I could help with much more, as I'd like to see it happen. We already have a system for building dependencies on/for various platforms (it already builds for windows), it would need to be adapted for use on Windows. You could then use them to build bitcoin with mingw, or coerce it into building with msvc.
I think a much more realistic next step would be to get a mingw environment up and running under Windows. That I could help with much more, as I'd like to see it happen. @theuni I am not sure if this is what you wanted to see but it looks like there is no easy way to get these generated files so I setup MinGW on Windows 7 and did the build. It builds the BitcoinD with no issues except it requires a fix for boost 1.56 bug which is described in workarounds directory. I didn't bother with QT but I am sure it could be done as well. https://github.com/ENikS/bitcoin-dev-mingw
Automatic sanity-testing: FAILED BUILD/TEST, see http://jenkins.bluematt.me/pull-tester/p4824_e283a31376a68e95dc5fbe88b114cacb09d46ffd/ for binaries and test log.
This could happen for one of several reasons:
If you believe this to be in error, please ping BlueMatt on freenode or TheBlueMatt here.
This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.
Seems pulltester's gcc genuinely can't deal with this code. I believe we'll drop the requirement of the ancient environment it runs on at some point in the future, but as long as it's there, we can't just break it.
Isn't this a c++11 feature anyway?
Yes, it is C++11. As far as I knew just about every compiler implements it, even these who do not support full C++11 spec (msvc for example). I guess only actively maintained do. It could be cast to unsigned during the comparison to eliminate the warning but it would be less elegant solution IMHO. Up to you...
Pulltester uses GCC 4.4 iirc, so it's missing many c++11 features. We'll likely drop pulltester soon, though.
I guess it can wait
Needs rebase; this structure is now in src/chain.h. Apart from that it can be merged now.
Looks like clang, which is used on macosx, has difficulties with this.
Closing this for now. Can be reopened when the consensus on using (subsets of) c++11 changes.