Building headless Bitcoin and Bitcoin-qt on Windows

[nitrogenetics]

I mean the wallet works and all but pops out a lot of errors when trying to close it.

Edit:
Works when compiled statically. Tested on both qt 4.8.5 and 5.2.

[1714043325]

1714043325

[1714043325]

1714043325

[1714043325]

1714043325

[1714043325]

1714043325

[1714043325]

1714043325

[1714043325]

1714043325

[Apocalipsis]

I mean the wallet works and all but pops out a lot of errors when trying to close it.

Edit:
Works when compiled statically. Tested on both qt 4.8.5 and 5.2.

When I close Compiled altcoin-qt.exe,it crashes,



What can it be?

[xslugx]

So I got everything to compile, and I got the .dll 's that are needed. Now the qt.exe file does not launch and the altcoind.exe just opens a cmd window anythoughts?

[old c coder]

I mean the wallet works and all but pops out a lot of errors when trying to close it.

Edit:
Works when compiled statically. Tested on both qt 4.8.5 and 5.2.

When I close Compiled altcoin-qt.exe,it crashes,
What can it be?

If you have been following this forum, the original static builds of bitcoin-qt.exe, built and run windows before bitcoin 0.8.5 and 0.8.6 all behaved erratically at exit. The cross compiled pre-built bitcoin-qt.exes that one got from source forge, generally behaved better at exit, though weren't perfect as I remember.

This means that if your *coin-qt.exe implementation is derived from a bitcoin qt sources pre 0.8.5, then you inherit all its capabilities and deficiencies.

The bitcoind.exes prebuilt from source forge may or may not have exited gracefully when commanded to "stop" remotely. I cannot say since I generally use a built on windows from sources bitcoind.exe. For me the bitcoind.exes built on windows exit more gracefully at 0.8.3 and above (0.8.5, 0.8.6) than previous versions.

So again, this means that if your *coind.exe implementation is derived from a bitcoind sources pre 0.8.3, then you inherit all its capabilities and deficiencies.

As an aside, if one has to abort, terminate or kill in some way a bitcoind.exe (and this goes for bitcoin-qt.exe too), there is no code to trap the 5 ways it can occur in Windows. The five ways are:
1. Ctl-C             (not in Qt)
2. Ctl-break       (not in Qt)
3. Close window (not in Qt)
4. Log-off user
5. Windows shutdown
The first two or three are under your control, the other two are not.
If you would like to trap those events, or some of them on Windows7, see message #176, on page 9 of this forum.

Hope this helps

Ron

[old c coder]

So I got everything to compile, and I got the .dll 's that are needed. Now the qt.exe file does not launch and the altcoind.exe just opens a cmd window anythoughts?

Everything may be OK with your *coind.exe program! Since this is a linux/unix style daemon, the philosophy is the less output the better. Are you giving it any command line arguments to start? You should. A -datadir="your favorite place to store blockchains, etc." would be good! A -conf="where and what your configuration file is" would be really good too!

Can you close the command window of the *coind.exe? What happens? Do you have a debug log file in you data directory? What does it say? All of these will give you information to work with.

How can you tell that your *coin-qt.exe doesn't launch? Do you get a message? Do you get a splash screen? Again, with arguments as above but applied to the *coin-qt.exe program, are there any debug log files? This should help you get closer to the truth.

Ron

[Apocalipsis]

I mean the wallet works and all but pops out a lot of errors when trying to close it.

Edit:
Works when compiled statically. Tested on both qt 4.8.5 and 5.2.

When I close Compiled altcoin-qt.exe,it crashes,
What can it be?

If you have been following this forum, the original static builds of bitcoin-qt.exe, built and run windows before bitcoin 0.8.5 and 0.8.6 all behaved erratically at exit. The cross compiled pre-built bitcoin-qt.exes that one got from source forge, generally behaved better at exit, though weren't perfect as I remember.

This means that if your *coin-qt.exe implementation is derived from a bitcoin qt sources pre 0.8.5, then you inherit all its capabilities and deficiencies.

The bitcoind.exes prebuilt from source forge may or may not have exited gracefully when commanded to "stop" remotely. I cannot say since I generally use a built on windows from sources bitcoind.exe. For me the bitcoind.exes built on windows exit more gracefully at 0.8.3 and above (0.8.5, 0.8.6) than previous versions.

So again, this means that if your *coind.exe implementation is derived from a bitcoind sources pre 0.8.3, then you inherit all its capabilities and deficiencies.

As an aside, if one has to abort, terminate or kill in some way a bitcoind.exe (and this goes for bitcoin-qt.exe too), there is no code to trap the 5 ways it can occur in Windows. The five ways are:
1. Ctl-C             (not in Qt)
2. Ctl-break       (not in Qt)
3. Close window (not in Qt)
4. Log-off user
5. Windows shutdown
The first two or three are under your control, the other two are not.
If you would like to trap those events, or some of them on Windows7, see message #176, on page 9 of this forum.

Hope this helps

Ron

Thank you for such good answer.
I 'll try.

[nitrogenetics]

I mean the wallet works and all but pops out a lot of errors when trying to close it.

Edit:
Works when compiled statically. Tested on both qt 4.8.5 and 5.2.

When I close Compiled altcoin-qt.exe,it crashes,

What can it be?

Did you compile a statically linked executable?
Build qt statically
eg

Code:

configure.bat -release -opensource -confirm-license -static -make libs -no-sql-sqlite -no-opengl -qt-zlib -qt-pcre -no-icu -no-gif -qt-libpng -qt-libjpeg -no-angle -no-vcproj -no-openssl -no-dbus -no-audio-backend -no-wmf-backend -no-qml-debug

then add static flags to your .pro file

Code:

--- C:/Users/devel/Desktop/bitcoin-qt.pro	Wed Jan 08 20:59:06 2014
+++ C:/litecoin-0.8.6.1/bitcoin-qt.pro	Wed Jan 08 02:15:12 2014
@@ -8,6 +8,7 @@
 DEFINES += QT_GUI BOOST_THREAD_USE_LIB BOOST_SPIRIT_THREADSAFE
 CONFIG += no_include_pwd
 CONFIG += thread
+CONFIG += static
 
 # for boost 1.37, add -mt to the boost libraries
 # use: qmake BOOST_LIB_SUFFIX=-mt
@@ -18,6 +19,15 @@
 # Dependency library locations can be customized with:
 #    BOOST_INCLUDE_PATH, BOOST_LIB_PATH, BDB_INCLUDE_PATH,
 #    BDB_LIB_PATH, OPENSSL_INCLUDE_PATH and OPENSSL_LIB_PATH respectively
+BOOST_LIB_SUFFIX=-mgw48-mt-s-1_55
+BOOST_INCLUDE_PATH=C:/deps/boost_1_55_0
+BOOST_LIB_PATH=C:/deps/boost_1_55_0/stage/lib
+BDB_INCLUDE_PATH=C:/deps/db-4.8.30.NC/build_unix
+BDB_LIB_PATH=C:/deps/db-4.8.30.NC/build_unix
+OPENSSL_INCLUDE_PATH=C:/deps/openssl-1.0.1e/include
+OPENSSL_LIB_PATH=C:/deps/openssl-1.0.1e
+MINIUPNPC_INCLUDE_PATH=C:/deps/
+MINIUPNPC_LIB_PATH=C:/deps/miniupnpc
 
 OBJECTS_DIR = build
 MOC_DIR = build
@@ -50,7 +60,8 @@
 # on Windows: enable GCC large address aware linker flag
 win32:QMAKE_LFLAGS *= -Wl,--large-address-aware
 # i686-w64-mingw32
-win32:QMAKE_LFLAGS *= -static-libgcc -static-libstdc++
+#win32:QMAKE_LFLAGS *= -static-libgcc -static-libstdc++
+win32:QMAKE_LFLAGS *= -static
 
 # use: qmake "USE_QRCODE=1"
 # libqrencode (http://fukuchi.org/works/qrencode/index.en.html) must be installed for support
@@ -112,7 +123,7 @@
         QMAKE_RANLIB = $$replace(QMAKE_STRIP, strip, ranlib)
     }
     LIBS += -lshlwapi
-    genleveldb.commands = cd $$PWD/src/leveldb && CC=$$QMAKE_CC CXX=$$QMAKE_CXX TARGET_OS=OS_WINDOWS_CROSSCOMPILE $(MAKE) OPT=\"$$QMAKE_CXXFLAGS $$QMAKE_CXXFLAGS_RELEASE\" libleveldb.a libmemenv.a && $$QMAKE_RANLIB $$PWD/src/leveldb/libleveldb.a && $$QMAKE_RANLIB $$PWD/src/leveldb/libmemenv.a
+    #genleveldb.commands = cd $$PWD/src/leveldb && CC=$$QMAKE_CC CXX=$$QMAKE_CXX TARGET_OS=OS_WINDOWS_CROSSCOMPILE $(MAKE) OPT=\"$$QMAKE_CXXFLAGS $$QMAKE_CXXFLAGS_RELEASE\" libleveldb.a libmemenv.a && $$QMAKE_RANLIB $$PWD/src/leveldb/libleveldb.a && $$QMAKE_RANLIB $$PWD/src/leveldb/libmemenv.a
 }
 genleveldb.target = $$PWD/src/leveldb/libleveldb.a
 genleveldb.depends = FORCE

[xslugx]

So I got everything to compile, and I got the .dll 's that are needed. Now the qt.exe file does not launch and the altcoind.exe just opens a cmd window anythoughts?

Everything may be OK with your *coind.exe program! Since this is a linux/unix style daemon, the philosophy is the less output the better. Are you giving it any command line arguments to start? You should. A -datadir="your favorite place to store blockchains, etc." would be good! A -conf="where and what your configuration file is" would be really good too!

Can you close the command window of the *coind.exe? What happens? Do you have a debug log file in you data directory? What does it say? All of these will give you information to work with.

How can you tell that your *coin-qt.exe doesn't launch? Do you get a message? Do you get a splash screen? Again, with arguments as above but applied to the *coin-qt.exe program, are there any debug log files? This should help you get closer to the truth.

Ron

No I am not giving the command args, I will try that in a bit. I can close the *coind.exe it errors, like everyone else's lol. So I did not think to look for a log, thank you for the tips I will get back to you when I try what is suggested.

[nitrogenetics]

First post updated:
-new compiler version
-removed obsolete db.h patch
-static build instructions only
-latest master branch build instructions added

[xslugx]

So I got everything to compile, and I got the .dll 's that are needed. Now the qt.exe file does not launch and the altcoind.exe just opens a cmd window anythoughts?

Everything may be OK with your *coind.exe program! Since this is a linux/unix style daemon, the philosophy is the less output the better. Are you giving it any command line arguments to start? You should. A -datadir="your favorite place to store blockchains, etc." would be good! A -conf="where and what your configuration file is" would be really good too!

Can you close the command window of the *coind.exe? What happens? Do you have a debug log file in you data directory? What does it say? All of these will give you information to work with.

How can you tell that your *coin-qt.exe doesn't launch? Do you get a message? Do you get a splash screen? Again, with arguments as above but applied to the *coin-qt.exe program, are there any debug log files? This should help you get closer to the truth.

Ron

So I believe there is just an issue with files that I have because it does not make sense the coin-qt.exe will not load, I have tried different coins with the same outcome. fresh VB with win 7 ultimate on it 32 bit, built in 64 bit same thing. I have to be missing something vital, I hear that it is a memory error, but I do not have the error code, I have someone else working on it with me and I try to run it in VS 2010 but it does not throw any errors

[Apocalipsis]

I mean the wallet works and all but pops out a lot of errors when trying to close it.

Edit:
Works when compiled statically. Tested on both qt 4.8.5 and 5.2.

When I close Compiled altcoin-qt.exe,it crashes,
What can it be?

If you have been following this forum, the original static builds of bitcoin-qt.exe, built and run windows before bitcoin 0.8.5 and 0.8.6 all behaved erratically at exit. The cross compiled pre-built bitcoin-qt.exes that one got from source forge, generally behaved better at exit, though weren't perfect as I remember.

This means that if your *coin-qt.exe implementation is derived from a bitcoin qt sources pre 0.8.5, then you inherit all its capabilities and deficiencies.

The bitcoind.exes prebuilt from source forge may or may not have exited gracefully when commanded to "stop" remotely. I cannot say since I generally use a built on windows from sources bitcoind.exe. For me the bitcoind.exes built on windows exit more gracefully at 0.8.3 and above (0.8.5, 0.8.6) than previous versions.

So again, this means that if your *coind.exe implementation is derived from a bitcoind sources pre 0.8.3, then you inherit all its capabilities and deficiencies.

As an aside, if one has to abort, terminate or kill in some way a bitcoind.exe (and this goes for bitcoin-qt.exe too), there is no code to trap the 5 ways it can occur in Windows. The five ways are:
1. Ctl-C             (not in Qt)
2. Ctl-break       (not in Qt)
3. Close window (not in Qt)
4. Log-off user
5. Windows shutdown
The first two or three are under your control, the other two are not.
If you would like to trap those events, or some of them on Windows7, see message #176, on page 9 of this forum.

Hope this helps

Ron

I think I found a problem.
It's in makefile-mingw of Litecoin
Is it different from bitcoin's makefile.mingw file?

If yes,can you write what i have to change,because i sepnt 3 hours ,and didn;t found.
Thanx in advice

[old c coder]

...
I think I found a problem.
It's in makefile-mingw of Litecoin
Is it different from bitcoin's makefile.mingw file?

If yes,can you write what i have to change,because i sepnt 3 hours ,and didn;t found.
Thanx in advice

Ah,

So finally we find out it's litecoin you are building. Well I don't follow litecoin. What version of litecoin? What version of bitcoin was/is litecoin basing its code from? There must be a litecoin specific forum where these matters are discussed? I don't know where it is though. It is hard enough just to keep track of bitcoin development

Is there a place where you can just download a pre-built litecoind.exe and litecoin-qt.exe versions for windows ala sourceforge where bitcoin prebuilt for windows releases may be had?

If you must build your own, I would suggest that you do something like the following. Build a bitcoind.exe and bitcoin-qt.exe for the version that litecoin is derived from first. Then build the litecoind and litecoin-qt.exe and note the differences in the code and the make files. Using the correct libraries and compiler for the bitcoin version chosen is important, I should think.

This would work for any *coin derived from bitcoin. 

Ron

[old c coder]

So I believe there is just an issue with files that I have because it does not make sense the coin-qt.exe will not load, I have tried different coins with the same outcome. fresh VB

does VB stand for VirtualBox?

with win 7 ultimate on it 32 bit, built in 64 bit same thing. I have to be missing something vital, I hear that it is a memory error, but I do not have the error code, I have someone else working on it with me and I try to run it in VS 2010 but it does not throw any errors

What *coin and what version are we talking about here? See message #334.

What can MSVC 2010 do for you since I assume you built or had built for you a bitcoin-qt.exe using gcc? Are you using some commercial third party add on such as http://visualgdb.com/tutorials/mingw/ to gdb your code, perhaps?

Ron

[raistlinthewiz]

bootstrap.bat mingw is broken for boost 1_55.

fix: https://groups.google.com/d/msg/boost-developers-archive/hVNKGbZcXs0/fIh-iK-DVOMJ

I've seen that also, however I couldn't reproduce the problem (it just worked like the previous versions did).
Did you need the workaround to compile boost? If so what are your system specs?

windows 8, x64. Yes i needed the workaround to compile a clean boost_1_55 download.

[xslugx]

So I believe there is just an issue with files that I have because it does not make sense the coin-qt.exe will not load, I have tried different coins with the same outcome. fresh VB

does VB stand for VirtualBox?

with win 7 ultimate on it 32 bit, built in 64 bit same thing. I have to be missing something vital, I hear that it is a memory error, but I do not have the error code, I have someone else working on it with me and I try to run it in VS 2010 but it does not throw any errors

What *coin and what version are we talking about here? See message #334.

What can MSVC 2010 do for you since I assume you built or had built for you a bitcoin-qt.exe using gcc? Are you using some commercial third party add on such as http://visualgdb.com/tutorials/mingw/ to gdb your code, perhaps?

Ron

As for MSVC I was running the exe itself in debug mode to catch any errors, but there was none. Anyway I solved my issues. There was a bad version of mingw32 somewhere in the mix, I only know because I removed everything and started clean and used easywinbuilder and it worked perfectly. I had previously tried easywinbuilder with no success but all is good now.

[microlost]

something wrong in my try:
1.The whole process is very smooth until the step 2.3 which I got a reply:b2 command not found
2.in step 3.3,I got a reply as:"*** missing separator . stop" after I run the command:mingw32-make -f makefile.ming

what is the matter?

[Claire123]

That is why I'm trying to offer an alternative build platform for Windows. The bitcoin source is the same. Not changed at all. Except with changes as above. It should (famous last words) be easier to pretty up a windows version in MSVC than in Qt. At least it seems so to me at this time. Qt is fine but it seems to have a lot of compatibility issues with its compiler, its libraries, etc.

Have you seen my thread on building BitcoinD and BitcoinQt using MSVC?

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

Are you saying you want to get rid of Qt and use native Windows GUI?

I wonder if you could just turn the daemon into a DLL and then put a C# wrapper around it?  I've discovered that doing a GUI in C# is way easier than Qt.

Also, concerning the aborts when closing the application: when I was porting the latest bitcoin source (the unreleased latest from github) to MSVC about a month ago, I found a bug in their shutdown sequence that caused aborts.  It was due the shutdown unwinding the bitdb object which needed to be explicity closed() first.  The abort was happening in the boost string code and was difficult to track down.

https://github.com/ClaireDuSoleil/bitcoin/commit/9987452a5d9c37afa8abf12abe85fc9429a3fb36

I don't know if this is what is causing this user's problem but I thought I would mention it.

[old c coder]

What *coin and what version are we talking about here? See message #334.
What can MSVC 2010 do for you since I assume you built or had built for you a bitcoin-qt.exe using gcc? Are you using some commercial third party add on such as http://visualgdb.com/tutorials/mingw/ to gdb your code, perhaps?
Ron

As for MSVC I was running the exe itself in debug mode to catch any errors, but there was none. Anyway I solved my issues. There was a bad version of mingw32 somewhere in the mix, I only know because I removed everything and started clean and used easywinbuilder and it worked perfectly. I had previously tried easywinbuilder with no success but all is good now.

That's great! You have succeeded, now you get to do it again with the next version. Or are you off to modify your *coin sources to do new and better things?

Ron

[old c coder]

Hello Claire123,

Fantastic!

That is why I'm trying to offer an alternative build platform for Windows. The bitcoin source is the same. Not changed at all. Except with changes as above. It should (famous last words) be easier to pretty up a windows version in MSVC than in Qt. At least it seems so to me at this time. Qt is fine but it seems to have a lot of compatibility issues with its compiler, its libraries, etc.

Have you seen my thread on building BitcoinD and BitcoinQt using MSVC?

No I have not.  But I will be going there as soon as I finish responding here!

https://bitcointalk.org/index.php?topic=349094
Are you saying you want to get rid of Qt and use native Windows GUI?

Not really.  I'm saying that on the Windows platform we should have more choices.  And a working MSVC++ solution would be a start, allowing for alternate GUIs and daemons, and programs to talk to a normal full client daemon, etc.

I wonder if you could just turn the daemon into a DLL and then put a C# wrapper around it?  I've discovered that doing a GUI in C# is way easier than Qt.

Yes, and MSVC++ can gui up and application in short order with those same VS drag and drop design tools, etc.  For the fun of it, I just GUI'd up the Qt look and feel in design view and could make a pretty good imitation, FWIW  in short order.  Nothing behind it though.

Also, concerning the aborts when closing the application: when I was porting the latest bitcoin source (the unreleased latest from github) to MSVC about a month ago, I found a bug in their shutdown sequence that caused aborts.  It was due the shutdown unwinding the bitdb object which needed to be explicity closed() first.  The abort was happening in the boost string code and was difficult to track down.

I think you have found the bug I have been remarking upon since version 0.8.2 came out. Congratulations!

https://github.com/ClaireDuSoleil/bitcoin/commit/9987452a5d9c37afa8abf12abe85fc9429a3fb36

I don't know if this is what is causing this user's problem but I thought I would mention it.

I will look at that too!  I couldn't wait and went to read the first link.  Wow!  And I have news for you.  I have an
addrman.h - serialize.h solution that compiles!
The reason MSVC++ gets ill at addrman.h as you say:

Addrman.h was especially difficult and I ended up ... giving MSVC fits.

was not only those extra (()); around the big IMPLEMENT_SERIALIZE(...) macro in the CAddrMan class, that implements GetSerializeSize() Serialize() and Unserialize(), but also the extra complexity of the imbedded std::map<int, int> mapUnkIds;!?

When the map<> is "levitated out" of the macro and placed in the #define IMPLEMENT_SERIALIZE(statements) macro in serialize.h the compiler hums!

My 0.8.5 MS'd sources compile fine.  But my MSVC++ static library build of the google levelDB blockchain database driver, seems to violate its own rules and I error at VerifyDB() at level 3, where serious levelDB "stuff" is happening.  Level 2 it's off to the races, until it gets a few new blocks and it actually has to write something to the .sst files in the chainstate directory.  I have tracked it down to (in levelDB source code terms)  the db/db_impl.cc code for DBImpl::Get(...) and possibly other methods' desire to do a MaybeScheduleCompaction.  The compaction deletes file(s) from the table of cached .sst files, somehow not notifying the rest of levelDB, and/or deleting them properly via DeleteEntry()!  Then when .sst file x is needed, db/table_cache.cc method TableCache::FindTable() doesn't find it in the table, and tries to open it, but it is open and Windows says no!  So FindTable() errors.

I think it is my MSVC++ version of levelDB (1.13 version) that isn't "locking" out the rest of itself correctly, when it is compacting, though I can't prove it.  When I compile out various MaybeScheduleCompaction() I can get through VerifyDB() at level 3, but when I get enough new blocks it still happens.  The result is a "spoiled" .sst file and so the whole chainstate index file system is vetoed and one must -reindex or bring a saved backup block testing blockchain to continue testing.  Which is what I have been doing for about a week now

I am very curious, needless to say, how you have built your levelDB static .lib file!  I used the
files given in a google discussion I found at:
https://groups.google.com/forum/#!topic/leveldb/VuECZMnsob4
see message from Edouard A dated 6/20/11 where there are three (magic) files:
port_win.h, port_win.cc and env_boost.cc
They almost did it for me!  The std:move() in env_boost.cc LockFile(...) stops me dead with my MSVC++.  I like the older ones that still can do a straight console app, a simple windows form (aka ol' dialog box app), doesn't have a broken (too much) intellisense, etc.
Anyway, I dug further and came upon this thread https://groups.google.com/forum/#!msg/leveldb/MpLZkz7rcHk/b9B3Eka6jdQJ with the same Edouard A  dated 7/3/12.  I used those files to create a levelDB113 static library project.  I will look forward to seeing how you did it!  See my message #322 on building the other static libraries.  Hope this helps.  I will Github some commits on a forked branch of 0.8.6 or 0.8.5 soon.  But I would like to have a truly working version first.

Ron

[r3wt]

Hello Claire123,

Fantastic!

That is why I'm trying to offer an alternative build platform for Windows. The bitcoin source is the same. Not changed at all. Except with changes as above. It should (famous last words) be easier to pretty up a windows version in MSVC than in Qt. At least it seems so to me at this time. Qt is fine but it seems to have a lot of compatibility issues with its compiler, its libraries, etc.

Have you seen my thread on building BitcoinD and BitcoinQt using MSVC?

No I have not.  But I will be going there as soon as I finish responding here!

https://bitcointalk.org/index.php?topic=349094
Are you saying you want to get rid of Qt and use native Windows GUI?

Not really.  I'm saying that on the Windows platform we should have more choices.  And a working MSVC++ solution would be a start, allowing for alternate GUIs and daemons, and programs to talk to a normal full client daemon, etc.

I wonder if you could just turn the daemon into a DLL and then put a C# wrapper around it?  I've discovered that doing a GUI in C# is way easier than Qt.

Yes, and MSVC++ can gui up and application in short order with those same VS drag and drop design tools, etc.  For the fun of it, I just GUI'd up the Qt look and feel in design view and could make a pretty good imitation, FWIW  in short order.  Nothing behind it though.

Also, concerning the aborts when closing the application: when I was porting the latest bitcoin source (the unreleased latest from github) to MSVC about a month ago, I found a bug in their shutdown sequence that caused aborts.  It was due the shutdown unwinding the bitdb object which needed to be explicity closed() first.  The abort was happening in the boost string code and was difficult to track down.

I think you have found the bug I have been remarking upon since version 0.8.2 came out. Congratulations!

https://github.com/ClaireDuSoleil/bitcoin/commit/9987452a5d9c37afa8abf12abe85fc9429a3fb36

I don't know if this is what is causing this user's problem but I thought I would mention it.

I will look at that too!  I couldn't wait and went to read the first link.  Wow!  And I have news for you.  I have an
addrman.h - serialize.h solution that compiles!
The reason MSVC++ gets ill at addrman.h as you say:

Addrman.h was especially difficult and I ended up ... giving MSVC fits.

was not only those extra (()); around the big IMPLEMENT_SERIALIZE(...) macro in the CAddrMan class, that implements GetSerializeSize() Serialize() and Unserialize(), but also the extra complexity of the imbedded std::map<int, int> mapUnkIds;!?

When the map<> is "levitated out" of the macro and placed in the #define IMPLEMENT_SERIALIZE(statements) macro in serialize.h the compiler hums!

My 0.8.5 MS'd sources compile fine.  But my MSVC++ static library build of the google levelDB blockchain database driver, seems to violate its own rules and I error at VerifyDB() at level 3, where serious levelDB "stuff" is happening.  Level 2 it's off to the races, until it gets a few new blocks and it actually has to write something to the .sst files in the chainstate directory.  I have tracked it down to (in levelDB source code terms)  the db/db_impl.cc code for DBImpl::Get(...) and possibly other methods' desire to do a MaybeScheduleCompaction.  The compaction deletes file(s) from the table of cached .sst files, somehow not notifying the rest of levelDB, and/or deleting them properly via DeleteEntry()!  Then when .sst file x is needed, db/table_cache.cc method TableCache::FindTable() doesn't find it in the table, and tries to open it, but it is open and Windows says no!  So FindTable() errors.

I think it is my MSVC++ version of levelDB (1.13 version) that isn't "locking" out the rest of itself correctly, when it is compacting, though I can't prove it.  When I compile out various MaybeScheduleCompaction() I can get through VerifyDB() at level 3, but when I get enough new blocks it still happens.  The result is a "spoiled" .sst file and so the whole chainstate index file system is vetoed and one must -reindex or bring a saved backup block testing blockchain to continue testing.  Which is what I have been doing for about a week now

I am very curious, needless to say, how you have built your levelDB static .lib file!  I used the
files given in a google discussion I found at:
https://groups.google.com/forum/#!topic/leveldb/VuECZMnsob4
see message from Edouard A dated 6/20/11 where there are three (magic) files:
port_win.h, port_win.cc and env_boost.cc
They almost did it for me!  The std:move() in env_boost.cc LockFile(...) stops me dead with my MSVC++.  I like the older ones that still can do a straight console app, a simple windows form (aka ol' dialog box app), doesn't have a broken (too much) intellisense, etc.
Anyway, I dug further and came upon this thread https://groups.google.com/forum/#!msg/leveldb/MpLZkz7rcHk/b9B3Eka6jdQJ with the same Edouard A  dated 7/3/12.  I used those files to create a levelDB113 static library project.  I will look forward to seeing how you did it!  See my message #322 on building the other static libraries.  Hope this helps.  I will Github some commits on a forked branch of 0.8.6 or 0.8.5 soon.  But I would like to have a truly working version first.

Ron

You make by far the most entertaining and knowledgeable posts on the forum. i enjoy reading them very much.
+1