(Now At Github) Bitcoin 0.8.6 for *VS2013* (32 and 64 bit) and Qt5.2

[TechAUmNu]

Hi Clare,

I have spent a while setting up everything and managed to compile everything apart from litecoinQt which fails with this error

Code:

'..\..\..\bitcoindeps\qt-everywhere-opensource-src-5.1.1\qtbase\bin\lrelease.exe' is not recognized as an internal or external command,

I have spent a while trying to figure out why lrealease isn't being built, since the folder is there and it all looks ok.
All of the dependencies seem to compile just fine, so I am confused what is going on.

Any ideas?

Edit: Got it to work by building qt 4.8.5 using mingw and then copying lrelease in the bin folder of qt 5.1.1

Thank you Clare123 for the awesome port!

[old c coder]

Hi Claire and other C++ experts,

Well, bitcointalk.org blew up taking the first version of this message into
oblivion, so I am reconstructing it as best I can.  I keep forgetting not to
compose in the window provided:(

Anyway, I downloaded the bitcoinqtmsvc2012-32138.zip version of 0.8.6
from codeplex, and my VC++ compiler has some "issues" with the  language in
regards the vector, among other things.

Looking at
http://msdn.microsoft.com/en-us/library/k449z507%28v=vs.80%29.aspx
for 2005 and
http://msdn.microsoft.com/en-us/library/9xd04bzs%28v=vs.110%29.aspx
for 2012,

notice that the data() method of vector does exist in 2005. 
Nor in 2008, it only "appeared" in 2010 and later versions!  So if one chooses
to not use &vch[0] and can't use vch.data(), could one use
&vch.at(0) or &(*vch.begin())?  Of course, one reads that
"unspecified" behavior results if there isn't (enough) data there!?  This
makes one wonder about the EvalScript() function is script.cpp. 

Also in serialize.h, an insert(..) method of CDataStream:

Code:

#ifndef _MSC_VER
    void insert(iterator it, std::vector<char>::const_iterator first, 
                                    std::vector<char>::const_iterator last)
    {
        assert(last - first >= 0);
        if (it == vch.begin() + nReadPos && (unsigned int)(last - first) <= nReadPos)
        {
            // special case for inserting at the front when there's room
            nReadPos -= (last - first);
            memcpy(&vch[nReadPos], &first[0], last - first);
        }
        else
            vch.insert(it, first, last);
    }
#endif

that you "removed" from VC++ 2012's view, happens to be the one that VC++ 2005
want's to use!  If I leave it as is, I get:

Code:

Compiling...
main.cpp
...\src\wallet.h(864) : error C2664: 
'void CDataStream::insert(CDataStream::iterator,CDataStream::size_type,const char &)' : 
cannot convert parameter 2 from 'std::_Vector_const_iterator<_Ty,_Alloc>' to 
'CDataStream::size_type'
        with
        [
            _Ty=char,
            _Alloc=std::allocator<char>
        ]
        No user-defined-conversion operator available that can perform this conversion, 
or the operator cannot be called

Build Time 0:08
Build log was saved at "file://...\Release\BuildLog.htm"
Bitcoin086CduS - 1 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Finally, in main.cpp, the
std::set<CBlockIndex*, CBlockIndexWorkComparator> setBlockIndexValid;
// may contain all CBlockIndex*'s that have validness >=BLOCK_VALID_TRANSACTIONS,
// and must contain those who aren't failed


compiles the same whether it is std::set<.. or ::set<.. or
set<.. for me. But since, in release mode, some arcane switches are different,
and the set has its erase() method called,  I get the compiler error:

Code:

Compiling...
main.cpp
D:\Program Files\Microsoft Visual Studio 8\VC\include\xtree(1174) : error C3848: 
expression having type 'const CBlockIndexWorkComparator' would lose some 
const-volatile qualifiers in order to call 'bool CBlockIndexWorkComparator::operator ()
(CBlockIndex *,CBlockIndex *)'
        D:\Program Files\Microsoft Visual Studio 8\VC\include\xtree(1169) : 
        while compiling class template member function 'std::_Tree_nod<_Traits>::_Node 
        *std::_Tree<_Traits>::_Lbound(CBlockIndex *const &) const'
        with
        [
            _Traits=std::_Tset_traits<CBlockIndex *,CBlockIndexWorkComparator,
                                                    std::allocator<CBlockIndex *>,false>
        ]
        D:\Program Files\Microsoft Visual Studio 8\VC\include\set(69) : 
        see reference to class template instantiation 'std::_Tree<_Traits>' being compiled
        with
        [
            _Traits=std::_Tset_traits<CBlockIndex *,CBlockIndexWorkComparator,
                                                    std::allocator<CBlockIndex *>,false>
        ]
        .\src\main.cpp(59) : see reference to class template instantiation 'std::set<_Kty,_Pr>' 
        being compiled
        with
        [
            _Kty=CBlockIndex *,
            _Pr=CBlockIndexWorkComparator
        ]
Build Time 0:15
Build log was saved at "file://...\Release\BuildLog.htm"
Bitcoin086CduS - 1 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

A cure i have is to change CBlockIndexWorkComparator in main.h to:

Code:

struct CBlockIndexWorkComparator
{
#ifdef _MSC_VER
    bool operator()(CBlockIndex *pa, CBlockIndex *pb) const
#else
    bool operator()(CBlockIndex *pa, CBlockIndex *pb)
#endif
    {
        if (pa->nChainWork > pb->nChainWork) return false;
        if (pa->nChainWork < pb->nChainWork) return true;

        if (pa->GetBlockHash() < pb->GetBlockHash()) return false;
        if (pa->GetBlockHash() > pb->GetBlockHash()) return true;

        return false; // identical blocks
    }
};

I can finally compile a release version without errors!  I don't know if
this is "kosher", but it looks OK to me?  Any comments?

Does anyone else have similar experiences?

In the words of Blaise Pascal:
I would have written a shorter letter, but I did not have the time.
Provincial Letters: Letter XVI, 4 December, 1656.

Ron

[Claire123]

Got it to work by building qt 4.8.5 using mingw and then copying lrelease in the bin folder of qt 5.1.1

Hi TechAU, I'm glad you got it working   For future reference and for others reading this, if you have the prerequisites installed, like Active-Perl and MSVC 12, then the batch files I wrote should build all of Qt, including lrelease:

https://bitcoinqtmsvc2012.codeplex.com/SourceControl/latest#MSVC/BuildHelpers/

This directory holds all the batch files.  You can look at buildqt32.bat to see what it's doing.  Note that the batch file does need to be edited for your directory locations and to update the configure line for your build location of OpenSsl.  Don't forget that part because if it starts building and can't find openssl, then you will have to start over with a clean copy of the qt distribution--at least I have to start over.

But if you are using some other build of Qt and don't want to deal with the translations, you can just delete the TS files from the project.  They aren't required unless you want to see the different languages.

Hi Claire and other C++ experts

Hi Ron, I'm glad you got the release mode working.  I think it was much easier for me being on a newer version of MSVC.  My first versions of the project did set the ITERATOR_DEBUG_FLAG off but I decided to see if I could get it turned back on by making some code changes to those vectors.   If I have time, I might remove some of the #ifdef statements dealing with CBlockIndexWorkComparator to see if the code compiles and works on Linux.  But, I've been swamped with work from my day job, which has morphed into getting Asterisk up and running on Red Hat so now it's vi and bash all the time for me...

By the way, I think you are the C++ expert here!  I just learn enough to be productive.  Every now and then I will refer to the Stroustrup book if I have to figure out code written by the real experts but I don't crack it open for pleasure reading...

[old c coder]

...
Hi Ron, I'm glad you got the release mode working.  I think it was much easier for me being on a newer version of MSVC.  My first versions of the project did set the ITERATOR_DEBUG_FLAG off but I decided to see if I could get it turned back on by making some code changes to those vectors.   If I have time, I might remove some of the #ifdef statements dealing with CBlockIndexWorkComparator to see if the code compiles and works on Linux.  But, I've been swamped with work from my day job, which has morphed into getting Asterisk up and running on Red Hat so now it's vi and bash all the time for me...

By the way, I think you are the C++ expert here!  I just learn enough to be productive.  Every now and then I will refer to the Stroustrup book if I have to figure out code written by the real experts but I don't crack it open for pleasure reading...

Hi Claire,

Release mode working?    I just said I was able to compile it without errors!  That is a long way from working!  I too have to set the define _HAS_ITERATOR_DEBUGGING=0 just in order to be able to run a debug version!  Actually I have to do even more.  The (first?) culprit is somewhere in VerifyDB() level 2, which I am chasing down now, now that I know a little more about vector.

The (first) actual error happens in the file ...Program Files\Microsoft Visual Studio 8\VC\include\vector in the

Code:

template<class _Ty, class _Ax> class vector

at the

Code:

reference operator[](size_type _Pos)
		{	// subscript mutable sequence
                  ...

operator, when the [argument] is >= size of the vector.  But even if one disables that check, the next one hits anyway!  Which is

Code:

            _SCL_SECURE_VALIDATE_RANGE(_Pos < size());

So I have to disable that one too!  Now I can actually run in debug mode.  But as I have said, after some time, usually an hour or two, the code DEBUG_LOCKCONTENTIONs somewhere in the RPC thread(s).  The hint is that the bitcoind code can no longer respond to RPC commands, other than help & stop (maybe other simple ones?).

Speaking of _DEBUG and NDEBUG mode, there seems to be a bit of chatter about bitcoind and bitcoin-qt (gcc on windows) versions having to be "debug" compiled?  Certainly the "older" makefile.mingw have the line
BOOST_SUFFIX?=-mgw46-mt-sd-1_52 and the -g argument, which most certainly is the debug version!  So a 64K question is: HAS ANYBODY gcc COMPILED A NON-DEBUG Bitcoind.exe?  And if so, did/does it work?  Really?  Then if it does, how about the Makefile.Release and Makefile.Debug files that make Bitcoin-qt.exe?  I see suspicious -lboost_program_options-mgw46-mt-sd-1_53 \ lines in there too.   Does the bitcoin-qt.pro python-esk qmake concoction make a distinction between debug and not debug in all its files?  I think it does, but one has to carefully check one's bitcoin-qt.pro and the Makefile.Release it produces to make sure everything is "Kosher".

Any thoughts, anyone?

And finally, which "the C++ Programming Language" are you referring to? We have:
First edition    1986,  328 pages
Second edition   1991,  669 pages
Third edition    1997,  962 pages
Fourth edition   2013, 1366 pages

I find them to be over-endowed with forward references, which makes it nearly impossible to learn from.  A logician would say there seems to be some circular definitions going on here.  No wonder compiler writers don't agree on what is or should be in many areas.  Be that as it may, what version of C++, be it C++99, C++2003, C++11 do you think the majority of bitcoin is written in?  It would help, I think, if we knew!

Another one of those short letters

Ron

[dbbit]

What is missing from these instructions is that it requires perl, python and nasm to be installed, and paths to be set up to it.

[Claire123]

What is missing from these instructions is that it requires perl and nasm to be installed, and paths to be set up to it.

Actually, I put a readme file in the build helper directory that says this:

These batch and project files build all the dependencies you need for the *coin daemon and Qt application, both 32 and 64 bit versions. But you need to fix them up before you can use them. The first thing you should do is move this folder to the root of your BitcoinDeps directory. You also need to make sure that ActivePerl is in your path and MSVC12 is installed in it's normal place. If not, edit the batch file as needed.

This readme is located here:
https://bitcoinqtmsvc2012.codeplex.com/SourceControl/latest#MSVC/BuildHelpers/README-FIRST.md

As far as nasm goes, I am using the nasm that comes with VS.  But in the past I have used the Netwide Assembler.  Is there any advantage to switching?

[dbbit]

Actually, I put a readme file in the build helper directory that says this:

These batch and project files build all the dependencies you need for the *coin daemon and Qt application, both 32 and 64 bit versions. But you need to fix them up before you can use them. The first thing you should do is move this folder to the root of your BitcoinDeps directory. You also need to make sure that ActivePerl is in your path and MSVC12 is installed in it's normal place. If not, edit the batch file as needed.

Ok, thanks - missed the perl path. But still needs python (and nasm) as well. Unfortunately the build scripts don't check for it in the beginning, so you could be compiling for an hour, only to have it fail after.

As far as nasm goes, I am using the nasm that comes with VS.  But in the past I have used the Netwide Assembler.  Is there any advantage to switching?

Visual Studio doesn't have a 'nasm'. It has masm (launched via ml.exe or ml64.exe). I don't mind using ml.exe but your openssl build script specifically looks for nasm. (In this case ml.exe was in my path if it wanted to use that instead.)

[Claire123]

Thanks, I updated my readme to include download links for the perl and python packages.

I'm pretty sure that nasm.exe and nasmw.exe now come with VS2012, at least the Ultimate version.

I really don't remember downloading them but don't have a fresh install to check.  I could be wrong

However, I also use VS2010 and that didn't come with any nasm exe files which is why I used Netwide in the past.

Edit.  I was wrong.  I had an old version of nasm lying around.  I will update my readme again.  Thanks!

[dbbit]

I have a bunch of link errors trying to build a 64-bit version of QT.

Qt5Core.lib(qstring.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MT_StaticRelease' in main.obj
Qt5Core.lib(qlist.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MT_StaticRelease' in main.obj
Qt5Core.lib(qarraydata.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MT_StaticRelease' in main.obj
Qt5Core.lib(qiodevice.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MT_StaticRelease' in main.obj
Qt5Core.lib(qcoreapplication.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MT_StaticRelease' in main.obj
Qt5Core.lib(qfiledevice.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MT_StaticRelease'
...
MSVCRT.lib(MSVCR110.dll) : error LNK2005: free already defined in LIBCMT.lib(free.obj)
MSVCRT.lib(MSVCR110.dll) : error LNK2005: malloc already defined in LIBCMT.lib(malloc.obj)
MSVCRT.lib(MSVCR110.dll) : error LNK2005: realloc already defined in LIBCMT.lib(realloc.obj)
MSVCRT.lib(MSVCR110.dll) : error LNK2005: memmove already defined in LIBCMT.lib(memcpy.obj)
MSVCRT.lib(MSVCR110.dll) : error LNK2005: memchr already defined in LIBCMT.lib(memchr.obj)
MSVCRT.lib(MSVCR110.dll) : error LNK2005: _ftelli64 already defined in LIBCMT.lib(ftelli64.obj)
MSVCRT.lib(MSVCR110.dll) : error LNK2005: _lseeki64 already defined in LIBCMT.lib(lseeki64.obj)
MSVCRT.lib(MSVCR110.dll) : error LNK2005: strcpy_s already defined in LIBCMT.lib(strcpy_s.obj)


Any idea how to resolve it?

[dbbit]

One more thing - the buildminiupnpc.bat script does not correctly build miniupnp.

There is no header from 'miniupnpcstrings.h', it's built if you run updateminiupnpcstrings.sh, which the build script doesn't do. Of course you can't just run a .sh in conhost, but if you run it under MinGW it gives a:


/* $Id: miniupnpcstrings.h.in,v 1.5 2012/10/16 16:48:26 nanard Exp $ */
/* Project: miniupnp
 * http://miniupnp.free.fr/ or http://miniupnp.tuxfamily.org/
 * Author: Thomas Bernard
 * Copyright (c) 2005-2011 Thomas Bernard
 * This software is subjects to the conditions detailed
 * in the LICENCE file provided within this distribution */
#ifndef MINIUPNPCSTRINGS_H_INCLUDED
#define MINIUPNPCSTRINGS_H_INCLUDED

#define OS_STRING "MINGW32_NT-6.2/1.0.18(0.48/3/2)"
#define MINIUPNPC_VERSION_STRING "1.8"

#endif


It would be useful to however build this file from your build script as well. You probably have an old one lying around in your directory created by MinGW which may be why it builds for you.

[Claire123]

Thank you for finding the upnp issue!   I have checked in a fix for the batch file.  When I was first working on the miniupnp code to create a suitable project file, I forgot that I had copied the .in to a .h to get it all to build and work.  My batch file doesn't put any meaningful information into those two strings but I don't think that will cause a problem. If it does, however, I can just create my own version of the .h file and copy it over to use for the miniupnp build.

As far as your Qt64 build issue, it sounds like an issue with dynamic vs static libs.  The statement in the batch file that calls perl to change the build options from dynamic to static in the qmake.conf file must run correctly.  If you are using a different version of VS, like 2010, then the batch file needs to modify a qmake.conf file in a different directory (as well as other changes)  Also, if you start building and anything goes wrong, don't start over unless you have a clean copy of the qt distribution.  It's pretty picky.   I hope this helps.

Thanks for trying all this out--I really appreciate it!

By the way, I have never used mingw on this machine--a Win 8 64 bit.  I did install mingw and built the bitcoin daemon only on another Windows system and that experience convinced me that something needed to change 

[dbbit]

Thank you for finding the upnp issue!   I have checked in a fix for the batch file.  When I was first working on the miniupnp code to create a suitable project file, I forgot that I had copied the .in to a .h to get it all to build and work.  My batch file doesn't put any meaningful information into those two strings but I don't think that will cause a problem. If it does, however, I can just create my own version of the .h file and copy it over to use for the miniupnp build.

As far as your Qt64 build issue, it sounds like an issue with dynamic vs static libs.  The statement in the batch file that calls perl to change the build options from dynamic to static in the qmake.conf file must run correctly.  If you are using a different version of VS, like 2010, then the batch file needs to modify a qmake.conf file in a different directory (as well as other changes)  Also, if you start building and anything goes wrong, don't start over unless you have a clean copy of the qt distribution.  It's pretty picky.   I hope this helps.

Thanks for trying all this out--I really appreciate it!

By the way, I have never used mingw on this machine--a Win 8 64 bit.  I did install mingw and built the bitcoin daemon only on another Windows system and that experience convinced me that something needed to change 

I am running on VS 2012 Ultimate, so that shouldn't be the problem. I finally gave up and downloaded the Qt from Digia that was already built.


I also found a problem with buildboost.bat though.

The bjam for x64 part works correctly, but the bjam for x86 is missing:
--toolset=msvc-11.0

With the result is it builds for the 12.0 toolset, and thus you can't link on x86 due to missing libs. Adding --toolset=msvc-11.0 solves it.

[Claire123]

Thanks, I will fix the boost batch file.  I never had any problem so I guess it was defaulting to the correct toolset on my system.  I don't have VS2013 installed yet.

[Claire123]

I modified the batch files that build Qt 32 and 64 to specify the visual studio version before building:

set VisualStudioVersion=11.0

This may solve issues with building Qt using VS2012 when you also have VS2013 installed.

I will be upgrading the project files to VS2013 in the next few weeks.

[old c coder]

...
Hi Ron, I'm glad you got the release mode working.  I think it was much easier for me being on a newer version of MSVC.  My first versions of the project did set the ITERATOR_DEBUG_FLAG off but I decided to see if I could get it turned back on by making some code changes to those vectors.   If I have time, I might remove some of the #ifdef statements dealing with CBlockIndexWorkComparator to see if the code compiles and works on Linux.  But, I've been swamped with work from my day job, which has morphed into getting Asterisk up and running on Red Hat so now it's vi and bash all the time for me...

By the way, I think you are the C++ expert here!  I just learn enough to be productive.  Every now and then I will refer to the Stroustrup book if I have to figure out code written by the real experts but I don't crack it open for pleasure reading...

Hi Claire,

Release mode working?    I just said I was able to compile it without errors!  That is a long way from working!  I too have to set the define _HAS_ITERATOR_DEBUGGING=0 just in order to be able to run a debug version!  Actually I have to do even more.  The (first?) culprit is somewhere in VerifyDB() level 2, which I am chasing down now, now that I know a little more about vector.
...
Speaking of _DEBUG and NDEBUG mode, there seems to be a bit of chatter about bitcoind and bitcoin-qt (gcc on windows) versions having to be "debug" compiled?  Certainly the "older" makefile.mingw have the line
BOOST_SUFFIX?=-mgw46-mt-sd-1_52 and the -g argument, which most certainly is the debug version!  So a 64K question is: HAS ANYBODY gcc COMPILED A NON-DEBUG Bitcoind.exe?  And if so, did/does it work?  Really?  Then if it does, how about the Makefile.Release and Makefile.Debug files that make Bitcoin-qt.exe?  I see suspicious -lboost_program_options-mgw46-mt-sd-1_53 \ lines in there too.   Does the bitcoin-qt.pro python-esk qmake concoction make a distinction between debug and not debug in all its files?  I think it does, but one has to carefully check one's bitcoin-qt.pro and the Makefile.Release it produces to make sure everything is "Kosher".

Any thoughts, anyone?
...

Hi all,

On 3/13/2014 ~ 12:00 EST, the leveldb dragon has been slain, and bitcoind now works in debug and release mode!  Much more to follow, stay tuned...

Videos on how to build your own BerkeleyDB 4.8.30, OpenSSL, Boost 1.53 (that one is easy!) and levelDB1.12 static multi-threaded libraries for MSVC++ 2005 or later (2008, 2010, 2011, 2012, 2013) Express or full.  And yes, *coind.exe's work too!

Ron

[Claire123]

Congratulations, Ron 

I have updated the opening post with new information.  As promised, I have project files and build scripts now for VS2013.  But, now, they are on Github.   The projects at codeplex will remain 0.8.6 and VS2012.

[LaitMan]

build 0.9.0 really?

[old c coder]

 

build 0.9.0 really?

Is that a question?   Or a comment?  Or a ?

Ron

[LaitMan]

build 0.9.0 really?

Is that a question?   Or a comment?  Or a ?

Ron

I want to make BTC wallet 0.9.0 version (in ubuntu and qt creator)
but here is a problem that file bitcoin-gt.pro which used for 0.8.6 is dissapeared.
But it suits for me variant of installation in VS

[Claire123]

build 0.9.0 really?

I am considering doing a port of 0.9.0 to VS2013, but I won't promise anything.  I am currently having fun and learning new things with other projects:

https://bitcointalk.org/index.php?topic=555155.0

I also want to learn more about cmake and possibly using that to create Visual Studio project files instead of writing them myself.