-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't compile on windows #33
Comments
Thanks for raising the issue! I don't have a development environment set up on my Windows machine yet. But in the meantime if you are willing to test out my branch, It seems like the C function mdb_env_get_fd returns |
Relates to #33 The type is a pointer on Windows and comparing a pointer to the value -1 is non-trivial in Go. The comparison has been replaced with a concise but delicate hack that is untested as of yet.
go build/go test on
go build for go test output for
|
Looking at the C code itself suggests you're correct - it's getting its value from either |
Thank you for testing and helping debug these issues, @hobocastle. That C warning looks like it could be serious. It may be worth investigating whether that is fixed in the latest version of the C library, and bringing it up in the OpenLDAP mailing list if it is not. Other than that, it seems I derped in that |
Getting there! I'll take a look at the causes of the new errors when I get in from work.
|
Hrm. This seems like a more challenging problem. It seems that the syscall package uses os specific Errno constants (e.g.
So the weird error message, "The device does not recognize the command." is actually a side effect of this behavior. I can correct the message fairly easily by using the function mentioned above. But I'm not yet sure what I want to do about the general problem of error handling. The function lmdb.IsErrnoSys function now seems very questionable. |
I have pushed a new commit to my branch. The end result is that the existing tests using errno values like The change effectively performs the translation from C (above), transforming return codes into the corresponding syscall.Errno values. Though it is a little hacky because it hardcodes C errno numbers instead of using names (not sure how to get around this best right now). I'm also a little disappointed with the solution because it uses build tags to exclude Go source files during compilation on different operating systems. But, go ahead and give it a try. It seems like we are getting very close to green tests. All the failures (sub one due to a missed usage of /tmp) are asserting about error handling. That should mean that the tests asserting proper usage of the library are passing. |
|
Adding
|
Ugh. Apologies about the build tags. Thank you for figuring it out. 😄 The I will look into these errors. But I am also going to get my own Windows development environment set up this weekend though. So hopefully we won't have to bounce back and forth more. Thanks again for all your help. |
@hobocastle, I was able to get a kludgey dev environment set up in Windows 10 under cygwin. In this environment I was able to get the remaining tests passing. Please check the latest commits out and let me know how they work for you. I will open a pull request and work on cleaning up any hacks before merging the changes in. |
Looks good. Obviously still has the warning from the C side, etc.
|
Thanks for all the help, @hobocastle. I've decided to include the fix in the 1.3.0 release. As we have discovered the problems were widespread and were not limited to something that I broke in the last release. But I am glad that we were able to get things working in a way that did not require changes to the exported API. Thanks again. |
Windows 7 Pro, 64 bit. mingw-w64. go 1.5.
Compilation fails with error "can't convert -1 to mdb_filehandle_t".
This appears to be caused by an assumption that the mdb_filehandle_t will be an int, which is not the case on Windows.
The text was updated successfully, but these errors were encountered: