Skip to content
This repository

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

Closed
wants to merge 9 commits into from

5 participants

Pieter Wuille Gavin Andresen P. Kaufmann Wladimir J. van der Laan BitcoinPullTester
Pieter Wuille
Collaborator

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.
Gavin Andresen

(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?

Pieter Wuille
Collaborator

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.

Gavin Andresen

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/

Gavin Andresen

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.

src/makefile.linux-mingw
((6 lines not shown))
92 92 DEFS += -I"$(CURDIR)/leveldb/include"
93 93 DEFS += -I"$(CURDIR)/leveldb/helpers"
94 94 leveldb/libleveldb.a:
95   - @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 ..
  95 + @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 ..
1
Gavin Andresen Owner

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Gavin Andresen

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

P. Kaufmann

@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.

Wladimir J. van der Laan
Owner

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
Pieter Wuille
Collaborator

@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.

Pieter Wuille
Collaborator

@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?

BitcoinPullTester

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)

Gavin Andresen

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.

Pieter Wuille
Collaborator

@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?

BitcoinPullTester

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)

P. Kaufmann

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?

bitcoin-qt.pro
... ... @@ -95,7 +97,7 @@ contains(BITCOIN_NEED_QT_PLUGINS, 1) {
95 97 }
96 98
97 99 INCLUDEPATH += src/leveldb/include src/leveldb/helpers
98   -LIBS += $$PWD/src/leveldb/libleveldb.a $$PWD/src/leveldb/libmemenv.a
  100 +LIBS += $$PWD/src/leveldb/libleveldb.a $$PWD/src/leveldb/libmemenv.a -lshlwapi -ldbghelp
2
P. Kaufmann
Diapolo added a note

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

Pieter Wuille Collaborator
sipa added a note

I forgot removing it from the Qt makefile.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
P. Kaufmann

@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.

Pieter Wuille
Collaborator

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

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

Gavin Andresen

@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.

Pieter Wuille
Collaborator

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?

Pieter Wuille
Collaborator

@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 :)

Gavin Andresen

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?

Pieter Wuille
Collaborator

@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...

Pieter Wuille
Collaborator

@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...

Gavin Andresen

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

P. Kaufmann

@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 :).

src/leveldb/build_detect_platform
((112 lines not shown))
123 131 PLATFORM=OS_WINDOWS
124   - COMMON_FLAGS="-fno-builtin-memcmp -D_REENTRANT -DOS_WINDOWS -DLEVELDB_PLATFORM_WINDOWS -DBOOST_THREAD_USE_LIB"
125   - PLATFORM_CXXFLAGS=""
126   - PLATFORM_LDFLAGS=""
  132 + COMMON_FLAGS="-fno-builtin-memcmp -D_REENTRANT -DOS_WINDOWS -DLEVELDB_PLATFORM_WINDOWS -DWINVER=0x0500 -posix"
1
Gavin Andresen Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
BitcoinPullTester

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)

Gavin Andresen

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

BitcoinPullTester

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)

P. Kaufmann Diapolo commented on the diff
bitcoin-qt.pro
... ... @@ -103,7 +105,8 @@ LIBS += $$PWD/src/leveldb/libleveldb.a $$PWD/src/leveldb/libmemenv.a
103 105 isEmpty(QMAKE_RANLIB) {
104 106 QMAKE_RANLIB = $$replace(QMAKE_STRIP, strip, ranlib)
105 107 }
106   - 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
  108 + LIBS += -lshlwapi
4
P. Kaufmann
Diapolo added a note

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 :).

Pieter Wuille Collaborator
sipa added a note

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.

P. Kaufmann
Diapolo added a note

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

Pieter Wuille Collaborator
sipa added a note

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
bitcoin-qt.pro
... ... @@ -103,7 +105,8 @@ LIBS += $$PWD/src/leveldb/libleveldb.a $$PWD/src/leveldb/libmemenv.a
103 105 isEmpty(QMAKE_RANLIB) {
104 106 QMAKE_RANLIB = $$replace(QMAKE_STRIP, strip, ranlib)
105 107 }
106   - 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
  108 + LIBS += -lshlwapi
  109 + 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
1
P. Kaufmann
Diapolo added a note

After OS_WINDOWS_CROSSCOMPILE we have an ", I'm not sure this should be in there :).

@sipa Can you remove that?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
P. Kaufmann Diapolo commented on the diff
src/leveldb/build_detect_platform
((112 lines not shown))
123 131 PLATFORM=OS_WINDOWS
124   - COMMON_FLAGS="-fno-builtin-memcmp -D_REENTRANT -DOS_WINDOWS -DLEVELDB_PLATFORM_WINDOWS -DBOOST_THREAD_USE_LIB"
125   - PLATFORM_CXXFLAGS=""
126   - PLATFORM_LDFLAGS=""
127   - PLATFORM_SHARED_CFLAGS=""
128   - PLATFORM_SOURCES="port/port_win.cc util/env_boost.cc util/win_logger.cc"
129   - 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"
  132 + COMMON_FLAGS="-fno-builtin-memcmp -D_REENTRANT -DOS_WINDOWS -DLEVELDB_PLATFORM_WINDOWS -DWINVER=0x0500 -D__USE_MINGW_ANSI_STDIO=1"
1
P. Kaufmann
Diapolo added a note

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
P. Kaufmann

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.

BitcoinPullTester

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)

BitcoinPullTester

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)

Diapolo and others added some commits
P. Kaufmann Diapolo 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
e813e14
Pieter Wuille sipa Replace leveldb/ with vanilla 1.7.0 bf6a13f
Pieter Wuille sipa 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
8fd3e1e
Pieter Wuille sipa Remove Snappy support cf556b2
Pieter Wuille sipa Pre-Vista leveldb::port::InitOnce implementation 6c3f8a1
Pieter Wuille sipa Use Boost 1.52 in Windows builds 1ded43c
Pieter Wuille sipa 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
1c3babb
Pieter Wuille sipa Mingw support for Windows LevelDB port 9bd70ff
Gavin Andresen gavinandresen 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
e21a778
BitcoinPullTester

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)

Gavin Andresen gavinandresen referenced this pull request
Merged

Leveldb 1.7 #2198

BitcoinPullTester

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

Pieter Wuille
Collaborator

closing, as #2198 is merged

Pieter Wuille sipa closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Showing 9 unique commits by 4 authors.

Jan 18, 2013
P. Kaufmann Diapolo 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
e813e14
Pieter Wuille sipa Replace leveldb/ with vanilla 1.7.0 bf6a13f
Pieter Wuille sipa 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
8fd3e1e
Pieter Wuille sipa Remove Snappy support cf556b2
Pieter Wuille sipa Pre-Vista leveldb::port::InitOnce implementation 6c3f8a1
Pieter Wuille sipa Use Boost 1.52 in Windows builds 1ded43c
Pieter Wuille sipa 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
1c3babb
Pieter Wuille sipa Mingw support for Windows LevelDB port 9bd70ff
Gavin Andresen gavinandresen 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
e21a778
Something went wrong with that request. Please try again.