Support for DragonFly BSD #5768
Comments
|
The stdlib FFI files are mostly generated for each platform, so I think we'd need to figure out how to regenerate them. The alternative, which might be easier (the generation process was not documented and we'd have to dig a bit) would be to just take one of the other BSDs and fix up any type widths etc. This would be great to get done for 9.2.8! |
|
But are they generated for every platform during the jruby build time, or is it pulled externally? |
|
@tuxillo They're generated manually, since we don't have a good rig to generate automatically on all these weird platforms. |
|
Okay then, if you come across the instructions to generate it maybe I can give it a shot :) |
|
By any chance you happened to come across the instructions? Thanks! |
|
@tuxillo Sorry for delay. I did not see this update... I believe if you cd to lib/ruby/stdlib/ffi/tools and run Can you give that a try? |
|
Not sure if I'm doing something wrong. After building JRuby (from master branch) and setting PATH I get this just by running Maybe something is wrong with my setup? |
|
@tuxillo Hmm that's interesting. This doesn't seem to be loading right. Can you check if there's any GEM-related environment variables? You can get the longer trace for the NullPointerException by passing -d to JRuby, e.g. |
|
I don't see any gem-related env variables. Here's the longer trace: |
|
Ok that's peculiar. The line in question is here: We know And looking at the logic inside that posix function, we see that errno is never set to anything: jruby/core/src/main/java/org/jruby/util/io/PosixShim.java Lines 425 to 428 in a141c69 I'll commit a fix that retrieves the errno and captures it in the |
|
I've pushed e255434 but of course it occurred to me that it's just going to raise an error here. Based on that error hopefully we'll have a better idea what's going on. I'll try to get my own DragonFly VM going also. |
|
Thanks @headius ! Now I indeed get a different error: Doing a ktrace (similar to linux's strace) I can see this: So in a call to I added a |
|
Ah that's interesting! So the really good news here is that it is making the native call. But the fcntl flags appear to not line up. This logic should be trying to do F_GETFD to get the file descriptor flags. On my system, that flag is "1" which does appear to match my system includes: In your case it appears to be sending F_SETLK, which is clearly not F_GETFD. On my system F_SETLK is 8, which shouldn't overlap. The values on DragonFly seem to match, though: https://github.com/DragonFlyBSD/DragonFlyBSD/blob/master/sys/sys/fcntl.h#L190-L224 Can you show me the output of the following command line on your system? I wonder if it's picking the wrong set of Fcntl values... |
|
Another couple to try: |
|
Another! |
|
Hi, Yeah, it's definitely picking up the wrong values: I've created this, not sure if i'ts completely correct: #5828 |
|
@tuxillo That's great! It was exactly what we suspected...those values are from the "fake" set of constants when we can't determine the platform. I've raised the issue with @enebo that we should regenerate these to mimic something a little closer to normal POSIX so that at least when it falls back most of the values should be right. As for your PR, it looks right to me. Does it make things work for you? I think we've missed the window for 9.2.8 but will be working to spin a 9.2.9 release MUCH more quickly. That will give us time to ensure things are working properly on your system. In the meantime, you might try this as a workaround and see what happens:
It might pick the wrong native library and go haywire, though. |
|
Thanks! It indeed detects the OS and uses the correct constants there: I wonder whether FreeBSD uses its own constants or so. |
|
I'd be surprised if there were much difference between the BSDs as far as these constants go, so as long as it's able to load native support ( |
|
Sorry that's |
|
After the "Prepare errno here, to prevent NPE from ..." I still get the same valeu from F_GETFD=8 Sorry if I'm missing something here! |
|
since there was work done to support this platform, it would be nice to have jnr/jnr-constants#61 for 9.2.9. ping @headius |
|
@ahorek Are we good here? I also merged in your openbsd update. |
|
thanks @headius ! there's one more thing, I tested it and unfortunatelly correct constants are still not loaded the reason is because the platform name to generate those constants is get from FFI but to use them we get a name from a java property I think that FFI gem should also be updated to identify dragonflybsd as a platform What would you recommend? related PRs I think we're very close! |
|
We don't keep backwards compatibility for the most part so I think having a platform called "dragonflybsd" is okay, but I am not sure if that's the question. |
|
I think the intention of https://github.com/ffi/ffi/pull/724/files#diff-db0e38803c251431bdf21ae8936ac3f6R38 was to unify the platform name that omits the specific version of a platform, but that doesn't happen if the platform is unknown, because at least we have to choose one name everywhere, so we don't have to search for |
|
Avoiding versioning in the platform is certainly best. I'm thinking a better long-term path would be to have a separate version field that can be used only when needed and populated from whatever properties make sense. As @ahorek points out we've only had a version-specific problem with FreeBSD; if we have another one at some point it may force the issue but I'm inclined to stick with version free platforms as much as possible right now. So I think if we get these changes merged in (and I'll manually make the change to JRuby's built-in FFI) we should be good. |
|
I've pulled in the jnr pull requests and updated JRuby to point at the new releases. I'm now working on a PR for JRuby 9.2.10 that will update all related files from the FFI gem so we can start single-sourcing them (See #5947 #5948). Thanks for the help everyone! Hopefully you can also help me get the shared files working properly! |
|
I can confirm it works fine! thanks again |
|
Me too! Many thanks guys! |
|
@headius what about the stdlib thing we mentioned at the beginning of this issue? |
|
@tuxillo That will have to wait a bit... See #5948 and the related PR and if you can help me get things green again that would be great! I want to make 9.2.10 use the exact same files as the ffi gem, so we can just default install it as part of the build to pick up all types configs and generated files. |
|
@headius I am not sure what I should do :) |
|
@tuxillo Most of the errors appear to be issues in the native parts of JRuby's FFI, probably things that evolved in the gem but were never propagated to the JRuby version. A large number of these are "got type X and expected Y" where Y should be able to coerce into X...so we're probably not doing the right coercion call (e.g. to_int or to_str) on the native side. If you can pull that branch and run those FFI specs, it would be a big help to reduce them down to just the couple of lines that fails, so we can iterate on the errors quickly and fix the internals. |
|
I started looking into it a bit and it seems like the main change we'll need to make is reconciling the ruby/native split to match the FFI gem. Several of the classes that were originally defined in C are now moved into Ruby, and with JRuby's versions still in Java we end up with conflicting logic. The first example I found was that the I'll poke at it a bit and push some changes to the PR that may help others assist. |
|
I've pushed a number of changes that reduces the failure count to 13. Mostly I'm just going spec by spec and looking to make logic match between the C FFI and the JRuby FFI. In many cases this just means removing the JRuby native version of some logic and allowing the Ruby logic to win. |
Hi,
No JRuby available for DragonFly BSD (www.dragonflybsd.org) and I'd like to know what would be the steps to have that OS included in the binary distribution.
We, at least, took what we thought the initial requirements, see: jnr/jnr-posix#127, jnr/jnr-ffi#184, jnr/jffi#64
Now, I cloned jruby's git repo and built distribution with this diff:
And
mvnw -Pdistcreates a .tar.gz with libjffi for DragonFly BSD but I see no stdlib/ffi.Thanks,
Antonio Huete
The text was updated successfully, but these errors were encountered: