LevelDB 1.7 + windows updates (MinGW-w64, Boost 1.52, Precise gitian VM) #2106

pull sipa wants to merge 9 commits into bitcoin:master from sipa:leveldb17 changing 44 files +1731 −1049
  1. sipa commented at 9:15 PM on December 13, 2012: member

    Several upgrades, each necessary to fix problem with the previous one. They could be separated, but at least this combination builds and works. It certainly needs a lot of testing, but I want to give it some exposure:

    • Upgrade to LevelDB 1.7
    • Switch to a native Windows LevelDB port (not anymore via Boost)
    • Switch to MinGW-w64 (32-bit mode) for Windows builds, as the new Windows port required a more recent GCC/environment than provided by MinGW32.
    • Switch to a 32-bit Precise image for Windows builds (which provides MinGW-w64 with GCC 4.6.3).
    • Switch to Boost 1.52, as Boost 1.50's thread library doesn't build on MinGW-w64.
  2. gavinandresen commented at 11:52 PM on December 13, 2012: contributor

    (retracted ACK)

    Can you give step-by-step gitian building commands; e.g. make_base_vm ?something? ... and which dependencies will we need to rebuild?

  3. sipa commented at 11:56 PM on December 13, 2012: member

    There's no way that ACK can mean you tested it, given the followup question...

    ./bin/make-base-vm --suite precise --arch i386

    Then rebuild Qt, Boost, and deps.

  4. gavinandresen commented at 1:37 AM on December 14, 2012: contributor

    mea culpa: ACK code changes.

    I'm making-base-vm now... ./bin/make-base-vm --suite precise --arch i386

    Fetch a new boost and qt for inputs: cd inputs wget https://downloads.sourceforge.net/project/boost/boost/1.52.0/boost_1_52_0.tar.bz2 wget http://releases.qt-project.org/qt4/source/qt-everywhere-opensource-src-4.8.4.tar.gz cd ..

    Build dependencies: ./bin/gbuild ../bitcoin/contrib/gitian-descriptors/boost-win32.yml && mv build/out/* inputs/ ./bin/gbuild ../bitcoin/contrib/gitian-descriptors/deps-win32.yml && mv build/out/* inputs/ ./bin/gbuild ../bitcoin/contrib/gitian-descriptors/qt-win32.yml && mv build/out/* inputs/

  5. gavinandresen commented at 4:05 PM on December 14, 2012: contributor

    Please update contrib/gitian-descriptors/README too (mention the new make-base-vm).

    Successfully gitian-built HEAD plus this pull.

    Running Bitcoin-Qt -testnet in a Virtual Box Windows XP service pack 3, 2GB memory VM:

    • Installer works properly
    • Runs, starts syncing with the chain ... but then crashes.

    I'll see if I can get a Windows debugging environment going to help debug the crash.

  6. in src/makefile.linux-mingw:None in e65f01a7ea outdated
      92 | +LIBS += $(CURDIR)/leveldb/libleveldb.a $(CURDIR)/leveldb/libmemenv.a -lshlwapi -ldbghelp
      93 |  DEFS += -I"$(CURDIR)/leveldb/include"
      94 |  DEFS += -I"$(CURDIR)/leveldb/helpers"
      95 |  leveldb/libleveldb.a:
      96 | -	@echo "Building LevelDB ..." && cd leveldb && CC=i586-mingw32msvc-gcc CXX=i586-mingw32msvc-g++ TARGET_OS=OS_WINDOWS_CROSSCOMPILE CXXFLAGS="-I$(INCLUDEPATHS)" LDFLAGS="-L$(LIBPATHS)" $(MAKE) libleveldb.a libmemenv.a && i586-mingw32msvc-ranlib libleveldb.a && i586-mingw32msvc-ranlib libmemenv.a && cd ..
      97 | +	@echo "Building LevelDB ..." && cd leveldb && CC=i686-w64-mingw32-gcc CXX=i686-w64-mingw32-g++ TARGET_OS=OS_WINDOWS_CROSSCOMPILE" $(MAKE) libleveldb.a libmemenv.a && i686-w64-mingw32-ranlib libleveldb.a && i686-w64-mingw32-ranlib libmemenv.a && cd ..
    


    gavinandresen commented at 10:06 PM on December 14, 2012:

    There is an extra double-quote here; wonder why that didn't break my gitian build...

  7. gavinandresen commented at 10:41 PM on December 14, 2012: contributor

    Results of running inside the mingw gdb (binary cross-compiled on my linux machine -g, then copied over): https://gist.github.com/4289251

  8. Diapolo commented at 9:44 AM on December 15, 2012: none

    @sipa If we have a new compiler ready with Gitian, #1674 should be tested also. Could you do a build with that integrated, as I guess pull-tester is not yet using the same compiler suite.

  9. laanwj commented at 12:21 PM on December 15, 2012: member

    I suck at gitian (yes, I changed the yml to point to sipa's repository, but somehow can't get it to work, I also tried leveldb17 instead of the hex id)

    bin/gbuild --commit bitcoin=e65f01a ../bitcoin/contrib/gitian-descriptors/gitian-win32.yml
    fatal: ambiguous argument 'e65f01a': unknown revision or path not in the working tree.
    Use '--' to separate paths from revisions
    bin/gbuild:204: error looking up commit for tag e65f01a (RuntimeError)
            from bin/gbuild:191:in `each'
            from bin/gbuild:191
    
  10. sipa commented at 2:09 PM on December 15, 2012: member

    @laanwj I've given up trying to make gitian fetch what I want by itself.

    I have a wrapper script at http://bitcoin.sipa.be/builds/bitcoin-build.sh.txt, which injects the commit you ask for from a local repository into gitian. It also does some other things like singing and packaging.

  11. sipa commented at 6:35 PM on December 15, 2012: member

    @gavinandresen I added a commit that changes the Logv implementation (to something based on our util.cpp's strprintf). It's not very efficient, but maybe this works better (strange va_list semantics?). Can you try again?

  12. BitcoinPullTester commented at 2:22 AM on December 16, 2012: none

    Automatic sanity-testing: FAILED BUILD/TEST, see http://jenkins.bluematt.me/pull-tester/5f710985e0ee97c70a5e67ec08e6d4023dda0ca1 for binaries and test log.

    This could happen for one of several reasons:

    1. It chanages paths in makefile.linux-mingw or otherwise changes build scripts in a way that made them incompatible with the automated testing scripts
    2. It does not build on either Linux i386 or Win32 (via MinGW cross compile)
    3. The test suite fails on either Linux i386 or Win32
    4. The block test-cases failed (lookup the first bNN identifier which failed in https://github.com/TheBlueMatt/test-scripts/blob/master/FullBlockTestGenerator.java)
  13. gavinandresen commented at 3:24 PM on December 21, 2012: contributor

    Okey dokey... I've been working through this in two Windows virtual machines, one mingw32 and one mingw64, and having trouble with both-- mingw32 with the new code, mingw64 with building dependencies properly.

    But, I think I'm one issue away from getting the mingw32 build working; see https://gist.github.com/4353422 for the diff.

    The last issue is to write a replacement for the DbgHelp library's MakeSureDirectoryPathExists function. I don't think relying on the DbgHelp library is a good idea; I doubt it is a part of a non-developers environment, so we'd have to ship the DLL and install it, which is always painful.

  14. sipa commented at 5:34 PM on December 22, 2012: member

    @gavinandresen Added your patch to this pull request, rebasing it after removing my alternate Logv inplementation.

    Is removing -O2 from the command line options accidental?

  15. BitcoinPullTester commented at 5:41 PM on December 22, 2012: none

    Automatic sanity-testing: FAILED BUILD/TEST, see http://jenkins.bluematt.me/pull-tester/59d0df6124deb2be88ee1cd23b4add47b27728f8 for binaries and test log.

    This could happen for one of several reasons:

    1. It chanages paths in makefile.linux-mingw or otherwise changes build scripts in a way that made them incompatible with the automated testing scripts
    2. It does not build on either Linux i386 or Win32 (via MinGW cross compile)
    3. The test suite fails on either Linux i386 or Win32
    4. The block test-cases failed (lookup the first bNN identifier which failed in https://github.com/TheBlueMatt/test-scripts/blob/master/FullBlockTestGenerator.java)
  16. Diapolo commented at 11:53 AM on January 1, 2013: none

    I'm currently taking a look at this and try to build it with my IDE... will report back later.

    Edit: Got an error, during linking: d:/mingw/bin/../lib/gcc/mingw32/4.7.2/../../../../mingw32/bin/ld.exe: cannot find -ldbghelp @sipa I fetched your leveldb17 branch, does this include Gavins last commit?

  17. in bitcoin-qt.pro:None in 59d0df6124 outdated
      96 | @@ -95,7 +97,7 @@ contains(BITCOIN_NEED_QT_PLUGINS, 1) {
      97 |  }
      98 |  
      99 |  INCLUDEPATH += src/leveldb/include src/leveldb/helpers
     100 | -LIBS += $$PWD/src/leveldb/libleveldb.a $$PWD/src/leveldb/libmemenv.a
     101 | +LIBS += $$PWD/src/leveldb/libleveldb.a $$PWD/src/leveldb/libmemenv.a -lshlwapi -ldbghelp
    


    Diapolo commented at 12:15 PM on January 1, 2013:

    I had to remove the -ldbghelp in order to get it compile.


    sipa commented at 6:00 PM on January 1, 2013:

    I forgot removing it from the Qt makefile.

  18. Diapolo commented at 7:01 PM on January 1, 2013: none

    @sipa Thanks for fixing. Can you now also remove that line, as we don't need Boost chrono with Boost 1.52. https://github.com/bitcoin/bitcoin/blob/master/bitcoin-qt.pro#L387

    Edit: What is the main benefit of this pull, does it fix certain known issues with Windows or should it be faster? A few more details would be very nice. I'm currently doing an IBD with test- and mainnet.

  19. sipa commented at 9:34 PM on January 1, 2013: member

    @gavinandresen Done (hope you didn't mind me modifying your commit).

    Did you see https://bitcointalk.org/index.php?topic=129861.msg1427066#msg1427066 ?

  20. gavinandresen commented at 10:24 PM on January 1, 2013: contributor

    @sipa : don't mind at all; I was lazy and didn't compile Qt libraries (or Bitcoin-Qt) on my Windows VM.

    RE: leveldb port using a ton of disk space on Windows: yes, saw that, it makes me want to cry... I do now have a VM that can run the mingw gdb, so hopefully "we" can reproduce/fix it, but I'm not looking forward to learning about the details of how leveldb works to figure out what is broken.

  21. sipa commented at 10:27 PM on January 1, 2013: member

    Well, the filenames are blahblah.(null), and as those names are constructed using snprintf (see db/filename.cc), I'd say there's something wrong with snprintf still. Sure that #define _snprintf you changed was harmless?

  22. sipa commented at 10:34 PM on January 1, 2013: member

    @Diapolo

    • The native windows backend for leveldb should be faster than the boost one.
    • Keeping up with more recent (and less-patched) LevelDB versions seems a good idea for future extensibility.
    • A more recent VM image to build with also means a more recent compiler, and things like link-time optimizations may gain us some performance as well.

    In any case, in theory, none of these should cause a degradation. Again has been proved however that the difference between theory and practice is that in theory there is none, but in practice there is :)

  23. gavinandresen commented at 10:37 PM on January 1, 2013: contributor

    Oh, that's the issue: snprintf(%llu) won't work on 32-bit windows / mingw32 ... (at least, I THINK that's the issue)

    Needs more research thought; what did the other windows leveldb port do?

  24. sipa commented at 10:42 PM on January 1, 2013: member

    @gavinandresen It uses the exact same snprintf construction - as this is not code that is specific to the Windows port at all. Then again, we have no reason to assume that the issue reported in that forum post doesn't already exist in the current git master...

  25. sipa commented at 10:46 PM on January 1, 2013: member

    @gavinandresen Maybe the solution is just replacing the %llu's in the current leveldb code by macros like PRI64u in the core code. I hate maintaining such patched trees though...

  26. gavinandresen commented at 12:27 AM on January 2, 2013: contributor

    Summarizing discussion from IRC:

    mingw and *printf and 64-bit formats are complicated; see: http://sourceforge.net/project/shownotes.php?release_id=24832

    Compiling leveldb -posix works for me in a 32-bit Win XP mingw32 environment. Patch: https://gist.github.com/4431213

  27. Diapolo commented at 3:06 PM on January 2, 2013: none

    @sipa I found http://blog.qt.digia.com/blog/2012/05/08/qt-commercial-support-weekly-19-how-to-write-your-own-static-library-with-qt-2/ which mentions a few things about static linking with Qt. Perhaps it's at least a little interesting for you. @gavinandresen When did you update your commit? I'm asking because I need to fetch the changes then :).

  28. in src/leveldb/build_detect_platform:None in ca17521b90 outdated
     164 | +    OS_WINDOWS_CROSSCOMPILE | NATIVE_WINDOWS)
     165 |          PLATFORM=OS_WINDOWS
     166 | -        COMMON_FLAGS="-fno-builtin-memcmp -D_REENTRANT -DOS_WINDOWS -DLEVELDB_PLATFORM_WINDOWS -DBOOST_THREAD_USE_LIB"
     167 | -        PLATFORM_CXXFLAGS=""
     168 | -        PLATFORM_LDFLAGS=""
     169 | +        COMMON_FLAGS="-fno-builtin-memcmp -D_REENTRANT -DOS_WINDOWS -DLEVELDB_PLATFORM_WINDOWS -DWINVER=0x0500 -posix"
    


    gavinandresen commented at 7:36 PM on January 2, 2013:

    Using -D__USE_MINGW_ANSI_STDIO=1 instead of -posix works with the i686-w64-mingw32-g++ cross-compiler.

    No idea why, either the cross-compiler -posix is different from the straight compiler, or the -w64 compiler is different.

  29. BitcoinPullTester commented at 8:36 AM on January 3, 2013: none

    Automatic sanity-testing: FAILED BUILD/TEST, see http://jenkins.bluematt.me/pull-tester/13a5f3a808ec983e99b6b20d573f6653e7750197 for binaries and test log.

    This could happen for one of several reasons:

    1. It chanages paths in makefile.linux-mingw or otherwise changes build scripts in a way that made them incompatible with the automated testing scripts
    2. It does not build on either Linux i386 or Win32 (via MinGW cross compile)
    3. The test suite fails on either Linux i386 or Win32
    4. The block test-cases failed (lookup the first bNN identifier which failed in https://github.com/TheBlueMatt/test-scripts/blob/master/FullBlockTestGenerator.java)
  30. gavinandresen commented at 3:20 PM on January 3, 2013: contributor

    I ran @sipa's latest gitian-compiled binary overnight in an XP VM on -testnet with no issues.

  31. BitcoinPullTester commented at 2:42 AM on January 4, 2013: none

    Automatic sanity-testing: FAILED BUILD/TEST, see http://jenkins.bluematt.me/pull-tester/f6d8bf5093aad8c55a84e20a4c6b52a89cee1d0a for binaries and test log.

    This could happen for one of several reasons:

    1. It chanages paths in makefile.linux-mingw or otherwise changes build scripts in a way that made them incompatible with the automated testing scripts
    2. It does not build on either Linux i386 or Win32 (via MinGW cross compile)
    3. The test suite fails on either Linux i386 or Win32
    4. The block test-cases failed (lookup the first bNN identifier which failed in https://github.com/TheBlueMatt/test-scripts/blob/master/FullBlockTestGenerator.java)
  32. in bitcoin-qt.pro:None in f6d8bf5093 outdated
     104 | @@ -103,7 +105,8 @@ LIBS += $$PWD/src/leveldb/libleveldb.a $$PWD/src/leveldb/libmemenv.a
     105 |      isEmpty(QMAKE_RANLIB) {
     106 |          QMAKE_RANLIB = $$replace(QMAKE_STRIP, strip, ranlib)
     107 |      }
     108 | -    genleveldb.commands = cd $$PWD/src/leveldb && CC=$$QMAKE_CC CXX=$$QMAKE_CXX TARGET_OS=OS_WINDOWS_CROSSCOMPILE CXXFLAGS="-I$$BOOST_INCLUDE_PATH" LDFLAGS="-L$$BOOST_LIB_PATH" $(MAKE) libleveldb.a libmemenv.a && $$QMAKE_RANLIB $$PWD/src/leveldb/libleveldb.a && $$QMAKE_RANLIB $$PWD/src/leveldb/libmemenv.a
     109 | +    LIBS += -lshlwapi
    


    Diapolo commented at 4:30 PM on January 4, 2013:

    One comment, see line 388, where we also add shlwapi. Isn't that a pure Windows thing, where we can use win32.LIBS += -lshlwapi here and remove that library from line 388 below?

    Edit: I made some tests and could remove that line here and it still links fine, because of line 388 I think :).


    sipa commented at 9:15 PM on January 4, 2013:

    It's there to be sure shlwapi ends up in the linker command line after libleveldb.a, as that depends on shlwapi itself. It's possible it's right by default, but it won't hurt.


    Diapolo commented at 11:57 AM on January 6, 2013:

    It' won't hurt, but IMO it would be cleaner to use win32.LIBS.


    sipa commented at 8:54 PM on January 6, 2013:

    It's already inside a windows {} block, so that would be redundant.

  33. in bitcoin-qt.pro:None in f6d8bf5093 outdated
     104 | @@ -103,7 +105,8 @@ LIBS += $$PWD/src/leveldb/libleveldb.a $$PWD/src/leveldb/libmemenv.a
     105 |      isEmpty(QMAKE_RANLIB) {
     106 |          QMAKE_RANLIB = $$replace(QMAKE_STRIP, strip, ranlib)
     107 |      }
     108 | -    genleveldb.commands = cd $$PWD/src/leveldb && CC=$$QMAKE_CC CXX=$$QMAKE_CXX TARGET_OS=OS_WINDOWS_CROSSCOMPILE CXXFLAGS="-I$$BOOST_INCLUDE_PATH" LDFLAGS="-L$$BOOST_LIB_PATH" $(MAKE) libleveldb.a libmemenv.a && $$QMAKE_RANLIB $$PWD/src/leveldb/libleveldb.a && $$QMAKE_RANLIB $$PWD/src/leveldb/libmemenv.a
     109 | +    LIBS += -lshlwapi
     110 | +    genleveldb.commands = cd $$PWD/src/leveldb && CC=$$QMAKE_CC CXX=$$QMAKE_CXX TARGET_OS=OS_WINDOWS_CROSSCOMPILE" $(MAKE) libleveldb.a libmemenv.a && $$QMAKE_RANLIB $$PWD/src/leveldb/libleveldb.a && $$QMAKE_RANLIB $$PWD/src/leveldb/libmemenv.a
    


    Diapolo commented at 4:39 PM on January 4, 2013:

    After OS_WINDOWS_CROSSCOMPILE we have an ", I'm not sure this should be in there :). @sipa Can you remove that?

  34. in src/leveldb/build_detect_platform:None in f6d8bf5093 outdated
     167 | -        PLATFORM_CXXFLAGS=""
     168 | -        PLATFORM_LDFLAGS=""
     169 | -        PLATFORM_SHARED_CFLAGS=""
     170 | -        PLATFORM_SOURCES="port/port_win.cc util/env_boost.cc util/win_logger.cc"
     171 | -        PLATFORM_EXTRALIBS="-lboost_system-mgw45-mt-s-1_50 -lboost_filesystem-mgw45-mt-s-1_50 -lboost_thread-mgw45-mt-s-1_50 -lboost_chrono-mgw45-mt-s-1_50"
     172 | +        COMMON_FLAGS="-fno-builtin-memcmp -D_REENTRANT -DOS_WINDOWS -DLEVELDB_PLATFORM_WINDOWS -DWINVER=0x0500 -D__USE_MINGW_ANSI_STDIO=1"
    


    Diapolo commented at 11:50 AM on January 6, 2013:

    I'm asking myself, why you chose Windows 2000 (0x0500) over WinXP (0x0501), which is what we require with Bitcoin anyway.

    Edit: The LevelDB libs are a little different with that switch, but they compile just fine. @sipa Any reason not to switch to XP with that flag?

  35. Diapolo commented at 2:38 PM on January 10, 2013: none

    Just a small feedback, I'm testing another IBD with this (emtpy datadir) and now have ~54000 blocks to download. Bitcoin-Qt is currently using ~745MB of RAM, which seems to be a quite high number. I'll take a look and see how this progresses now. @sipa 28000 Blocks to go and now it's using ~1GB RAM. 14000 Blocks to go and now it's using ~1.1GB RAM.

  36. BitcoinPullTester commented at 11:39 PM on January 13, 2013: none

    Automatic sanity-testing: FAILED BUILD/TEST, see http://jenkins.bluematt.me/pull-tester/02fd69985969076f3cd0b2a645a56de6059138a5 for binaries and test log.

    This could happen for one of several reasons:

    1. It chanages paths in makefile.linux-mingw or otherwise changes build scripts in a way that made them incompatible with the automated testing scripts
    2. It does not build on either Linux i386 or Win32 (via MinGW cross compile)
    3. The test suite fails on either Linux i386 or Win32
    4. The block test-cases failed (lookup the first bNN identifier which failed in https://github.com/TheBlueMatt/test-scripts/blob/master/FullBlockTestGenerator.java)
  37. BitcoinPullTester commented at 10:47 PM on January 14, 2013: none

    Automatic sanity-testing: FAILED BUILD/TEST, see http://jenkins.bluematt.me/pull-tester/8f79bccc36cbb7234da08db8ea22a6ce37f5d5a8 for binaries and test log.

    This could happen for one of several reasons:

    1. It chanages paths in makefile.linux-mingw or otherwise changes build scripts in a way that made them incompatible with the automated testing scripts
    2. It does not build on either Linux i386 or Win32 (via MinGW cross compile)
    3. The test suite fails on either Linux i386 or Win32
    4. The block test-cases failed (lookup the first bNN identifier which failed in https://github.com/TheBlueMatt/test-scripts/blob/master/FullBlockTestGenerator.java)
  38. Replace leveldb/ with vanilla 1.7.0 bf6a13f046
  39. Remove Snappy support cf556b2c7d
  40. Native Windows LevelDB port
    Import native Windows LevelDB port by Hiram Chirino.
    
    Extracted from from https://github.com/chirino/leveldb.git using
    git diff dd0d562..aea83b7
    1c3babb7bf
  41. Mingw support for Windows LevelDB port 9bd70ff8ee
  42. Pre-Vista leveldb::port::InitOnce implementation 6c3f8a1e10
  43. Update makefiles/gitian for LevelDB 1.7, Ubuntu Precise, MinGW-W64
    Updates:
     * Update linux-mingw and bitcoin-qt.pro for LevelDB 1.7
     * Update gitian base VM image to precise
     * Use MinGW-w64 for Win32 builds
    8fd3e1e74c
  44. Use Boost 1.52 in Windows builds 1ded43cce3
  45. Port leveldb to MinGW32
    Several changes to make the native windows leveldb code compile
    with mingw32 and run on 32-bit Windows:
    * Remove -std=c++0x dependency (modified code to use NULL instead of
      nullptr)
    * Link with -lshlwapi
    * Only #define snprintf/etc if compiling with Visual Studio
    * Do not link against DbgHelp.lib (wrote a CreateDir instead of using
      DbgHelp's MakeSureDirectoryPathExists
    * Define WINVER=0x0500 so MinGW32 can use the 64-bit-filesystem Windows
      api calls
    * Define __USE_MINGW_ANSI_STDIO=1 to use MinGW's printf (which supports
      %ll)
    
    I also cleaned up makefile.mingw, assuming that dependencies would be in
    the standard /usr/local/{include,lib} by default but allowing overriding
    with make DEPSDIR=... etc
    e21a778c0a
  46. Windows-only: expand GCC Stack-Smashing Protector usage
    - enable -fstack-protector-all and static linking for Windows, which
      should result in a binary that is not dependent on libssp-0.dll
    - add missing -Wstack-protector flag to CFLAGS in makefile.mingw and
      makefile.linux-mingw
    - add a comment to these makefiles also
    e813e14f68
  47. BitcoinPullTester commented at 1:57 PM on January 18, 2013: none

    Automatic sanity-testing: FAILED BUILD/TEST, see http://jenkins.bluematt.me/pull-tester/e813e14f68a844c0c6c364aa66f9040f06e56bfe for binaries and test log.

    This could happen for one of several reasons:

    1. It chanages paths in makefile.linux-mingw or otherwise changes build scripts in a way that made them incompatible with the automated testing scripts
    2. It does not build on either Linux i386 or Win32 (via MinGW cross compile)
    3. The test suite fails on either Linux i386 or Win32
    4. The block test-cases failed (lookup the first bNN identifier which failed in https://github.com/TheBlueMatt/test-scripts/blob/master/FullBlockTestGenerator.java)
  48. BitcoinPullTester commented at 6:25 AM on January 24, 2013: none

    Automatic sanity-testing: FAILED MERGE, see http://jenkins.bluematt.me/pull-tester/e813e14f68a844c0c6c364aa66f9040f06e56bfe for test log.

    This pull does not merge cleanly onto current master

  49. sipa commented at 4:32 PM on January 24, 2013: member

    closing, as #2198 is merged

  50. sipa closed this on Jan 24, 2013

  51. HashUnlimited referenced this in commit 6b8b88aea7 on Jun 11, 2018
  52. sidhujag referenced this in commit 0076d47dcf on Jul 6, 2018
  53. DrahtBot locked this on Sep 8, 2021

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-04-17 03:15 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me