Building for windows. Again.

2015-11-19 Thread Kristoffer Sjögren
Hi I'm trying to build LMDB with Java/JNI bindings with Visual C++ Project Builder 9.00.30729 (vcbuild). Unfortunately, vcbuild don't ship with inttypes.h, stdint.h, or a sane ssize_t. So I searched around and found a few candidates [1] of inttypes.h and stdint.h that seems to be working for py-l

Re: Building for windows. Again.

2015-11-19 Thread Kristoffer Sjögren
The vcbuild file is found here [2]. Note that the project builds fine but tests fail and succeed sporadically. [2] https://github.com/deephacks/lmdbjni/blob/master/lmdbjni/src/main/native-package/vs2010.vcxproj On Thu, Nov 19, 2015 at 9:27 PM, Kristoffer Sjögren wrote: > Hi > > I'm trying to bu

Re: Building for windows. Again.

2015-11-19 Thread Howard Chu
Kristoffer Sjögren wrote: Hi I'm trying to build LMDB with Java/JNI bindings with Visual C++ Project Builder 9.00.30729 (vcbuild). Unfortunately, vcbuild don't ship with inttypes.h, stdint.h, or a sane ssize_t. So I searched around and found a few candidates [1] of inttypes.h and stdint.h that

Re: Building for windows. Again.

2015-11-19 Thread Kristoffer Sjögren
That's the thing, the build doesn't complain about anything missing. But the binary seems broken because tests fail randomly. A user tried the generated binary on his machine and it worked but also said... "Hm, almost, the database file is no longer put to the requested directory, and its name is

Re: Building for windows. Again.

2015-11-19 Thread Kristoffer Sjögren
The actual build command: $ cmd.exe /X /C "vcbuild /platform:x64 vs2008.vcproj release" On Thu, Nov 19, 2015 at 10:11 PM, Kristoffer Sjögren wrote: > That's the thing, the build doesn't complain about anything missing. > But the binary seems broken because tests fail randomly. > > A user tried t

Re: Building for windows. Again.

2015-11-19 Thread Kristoffer Sjögren
The py-lmdb project have a comment [1] about reusing Python.h headers which seems to work for them. # Microsoft Visual Studio 9 ships with neither inttypes.h, stdint.h, or a sane # definition for ssize_t, so here we add lib/win32 to the search path, which # contains emulation header files provided

Re: Building for windows. Again.

2015-11-19 Thread Howard Chu
Kristoffer Sjögren wrote: The py-lmdb project have a comment [1] about reusing Python.h headers which seems to work for them. # Microsoft Visual Studio 9 ships with neither inttypes.h, stdint.h, or a sane # definition for ssize_t, so here we add lib/win32 to the search path, which # contains emu

Re: Building for windows. Again.

2015-11-19 Thread Kristoffer Sjögren
I can see the problem now from a local test. Hmm i'm a bit confused. The JNI code uses GetStringUTFChars calls [1] for all char * arguments going from Java to C, which is an array of bytes representing the string in modified UTF-8 encoding. Is this OK? The other option is to use GetStringChars whi

Re: Building for windows. Again.

2015-11-19 Thread Kristoffer Sjögren
Oh, but the build file [2] have a CharacterSet element set to Unicode. Let me see if I can change this. [2] https://github.com/deephacks/lmdbjni/blob/master/lmdbjni/src/main/native-package/vs2010.vcxproj On Thu, Nov 19, 2015 at 11:45 PM, Kristoffer Sjögren wrote: > I can see the problem now fro

Re: Building for windows. Again.

2015-11-19 Thread Kristoffer Sjögren
Changing CharacterSet in the build file doesn't affect the garbled path. I tried to use explicit GetStringChars from the JNI code but with same result. Any pointers? I'm running short of ideas.. On Thu, Nov 19, 2015 at 11:55 PM, Kristoffer Sjögren wrote: > Oh, but the build file [2] have a Char

Re: Building for windows. Again.

2015-11-19 Thread Howard Chu
Kristoffer Sjögren wrote: Changing CharacterSet in the build file doesn't affect the garbled path. I tried to use explicit GetStringChars from the JNI code but with same result. Any pointers? I'm running short of ideas.. Looks like we need to use UTF-8, as in ITS#7992. I've just merged that p

Re: Building for windows. Again.

2015-11-20 Thread Kristoffer Sjögren
Yep, the commit fixes the problem. Thanks Howard! On Fri, Nov 20, 2015 at 2:14 AM, Howard Chu wrote: > Kristoffer Sjögren wrote: >> >> Changing CharacterSet in the build file doesn't affect the garbled path. >> >> I tried to use explicit GetStringChars from the JNI code but with same >> result. >

Re: Building for windows. Again.

2015-11-20 Thread Howard Chu
Kristoffer Sjögren wrote: Yep, the commit fixes the problem. Thanks Howard! The only question now - what is "modified" in the Java UTF-8 encoding? On Fri, Nov 20, 2015 at 2:14 AM, Howard Chu wrote: Kristoffer Sjögren wrote: Changing CharacterSet in the build file doesn't affect the garble

Re: Building for windows. Again.

2015-11-20 Thread Kristoffer Sjögren
The last build I know worked for lmdbjni on windows used LMDB_0.9.14. I was going to try a patch release on LMDB_0.9.16 but the fix doesn't merge cleanly. On Fri, Nov 20, 2015 at 10:26 AM, Howard Chu wrote: > Kristoffer Sjögren wrote: >> >> Yep, the commit fixes the problem. Thanks Howard! > > >

Re: Building for windows. Again.

2015-11-20 Thread Kristoffer Sjögren
Just to let you know. I merged the fix manually onto LMDB_0.9.16 and it works. https://github.com/deephacks/lmdbjni/commit/54a6ed3f1e0896a29e4bd10594bf9c80b0b25c65 On Fri, Nov 20, 2015 at 10:34 AM, Kristoffer Sjögren wrote: > The last build I know worked for lmdbjni on windows used LMDB_0.9.14.

Re: Building for windows. Again.

2015-11-20 Thread Howard Chu
Kristoffer Sjögren wrote: Just to let you know. I merged the fix manually onto LMDB_0.9.16 and it works. Great. But as we announced just last week http://www.openldap.org/lists/openldap-technical/201511/msg00092.html LMDB 0.9.17 is in preparation for release now. Probably will be out in a few

Re: Building for windows. Again.

2015-11-20 Thread Kristoffer Sjögren
Nice! I'll add the fix to that release then. On Fri, Nov 20, 2015 at 12:26 PM, Howard Chu wrote: > Kristoffer Sjögren wrote: >> >> Just to let you know. I merged the fix manually onto LMDB_0.9.16 and it >> works. > > > Great. But as we announced just last week > http://www.openldap.org/lists/open