NotImplementedError: flock unsupported or native support failed to load #3409
Comments
|
That's strange...flock should work fine. Can you try running it with JRUBY_OPTS="-Xnative.verbose=true" and post the output? |
|
I got the same exception |
|
Ok for some reason on your system our native subsystem is not loading, and the fallback to a pure-Java flock is not working. A couple things to check:
|
|
Tmp is standard location (/tmp), no security measures in place. It's my dev laptop. I did get it working. Apt said I had 2 packets that were no longer necessairy lib32z1 and libc6-i386. After an apt-get autoremove the problem was gone. (it removed /lib32/libcrypt.so.1 and left only /lib/x86_64-linux-gnu/libcrypt.so.1) |
|
Ahh so this would likely be an issue loading the wrong bit-width version of crypt. I'll talk with @enebo about how to avoid this in the future. Thanks for the update! |
|
@akkie Perhaps @Slicertje's fix would work for you too? |
|
Unfortunately I can't reproduce the issue even with lib32z1 and libc6-i386 installed. @Slicertje What env vars do you have relating to LD_LIBRARY*? |
|
Also LD64_LIBRARY or other variations. |
|
I can reproduce it on my linux box with having mutliarch enabled since I
needed some 32bit only libraries. then the new search for finding the lib
picks the wrong one.
|
|
see also my stacktrace in #3380 (comment) |
|
@mkristian How do you enable multiarch? |
|
@headius I do not remember but something along this howto https://wiki.debian.org/Multiarch/HOWTO on ubuntu (I did it already a few times and each time it is different then the last time) |
|
@mkristian Well phooey... my Ubuntu says it supports both i386 and x86_64 according to that page, but I don't get the wrong files loading. Do you have any unusual LD(64)LIBRARY* env? |
|
Marking this for 9.0.5 because the workaround is reasonably simple. There's obviously something wrong in our library selection logic (or the logic in https://github.com/jnr/jffi) that's picking the wrong bit-width and trying to run it. |
|
possible - if I want to install a game I can be very persistent. I can look into this since I have reproducible case but not before Tuesday, since I am off to visit my son over the weekend. |
|
@mkristian That would be great. I will keep trying to reproduce, but we have to get ready for JavaOne next week. |
|
@mkristian Oh, you might try running jnr-posix tests. If you can get them to fail you'll have a much easier path to figuring out why jffi/jnr-ffi is loading the wrong lib. |
|
@headius No it doesn't solve the issue on my machine. I also have a multiarch system and running |
using ld.so.conf on multiarch linux systems will include search paths for both 32 and 64 architecture. when finding the native library we need to look only at the paths which contains the libraries for the cpu in use. fixes jruby/jruby#3409 Sponsored by Lookout Inc.
|
@headius since you have already a multiarch system then I guess you just need to install and so all those lib32/i386 or x86_64 paths can/do cause problems with the current search logic. |
|
@mkristian Ahh, I did not have the |
|
Well I managed to get it to fail but I kinda had to force it a little: Before this my LD_LIBRARY_PATH was not set at all, nor was LD64_LIBRARY_PATH. I believe my ld.so.conf files are about like @mkristian's, with lib32 only in the "zz" file. I will proceed to try to make jffi/jnr-ffi deal with my case, but I still would like to see LD*LIBRARY_PATH env from those of you having this problem. |
|
Also, anyone having this issue could provide the output of following command:
|
|
@headius did you try the jnr-ffi with jnr/jnr-ffi#52 on your forced LD_LIBRARY_PATH - could already resolve your problem. |
|
@mkristian a-ha, I had forgotten that one. I will try it. This won't go into 9.0.4 in any case because I don't believe it's a new issue, but if jnr/jnr-ffi#52 works we'll roll it into 9.0.5 and let it bake on master until that release. |
|
So here's the deal...we've rolled JRuby master to jnr-ffi 2.0.5 which we believe fixes the reported issues here. It does not fix my LD_LIBRARY_PATH case but I believe that one is pretty artificial...basically forcing a 32-bit library path into the env running 64-bit stuff, bypassing ld.so.conf logic and appropriate path calculations based on it. We would VERY MUCH like for you folks to verify this with JRuby master, and to that end I have forced a dist build here: https://projectodd.ci.cloudbees.com/view/JRuby/job/jruby-master-dist/66/ When that completes, http://ci.jruby.org will contain updated 9.0.4 builds including the jnr-ffi update for you to verify. |
|
I still have the problem on my desktop. But I tried jruby-bin-9.0.4.0-SNAPSHOT.tar.gz and have no error any more: |
|
I have the problem on ubuntu 14.04 with a fresh 9.0.4.0-SNAPSHOT: |
|
@richtmat I need more info on your setup:
sorry so many questions but we need to be able to reproduce your problem :) |
|
@mkristian no problem. thanks for the help! JDK, installed via apt-get, package is oracle-java8-installer: without native enabled: verbose: |
|
any chance you can tell me how you got /libx32/libcrypt.so.1 onto your system. the new jnr-ffi does handle lib32 directories but not libx32 directories :( |
|
@mkristian I don't know to be honest. How do I even find out? |
|
@richtmat no problem. the latest patch is not enough for your case: jnr/jnr-ffi@3b4725d#diff-1d195f2e86fc2b08a79caba9a89d0856R444 the fix for this is obvious :) |
there are indeed /libx32/ on ubuntu 14.04 using the oracle-java8-installer package. this patch is to make the detection of those directories more lenient. fixes jruby/jruby#3409 Sponsored by Lookout Inc.
|
So we have part of the fix in for 9.0.4 but not all of it, is that correct? |
|
I just tried to install jruby-9.0.5.0 on alpine linux inside docker container and got the same error. I'm assuming that is because flock is part of busybox. Seems to be related to this issue gliderlabs/docker-alpine#11 |
|
@Gonzih Ahh, very good information, thanks. Hopefully they'll figure out a way to resolve that issue, and if anyone else runs into it they'll find your comment. |
|
@headius apparently current solution is to bring glibc in to alpine linux to run jvm :) |
…resolved in jruby-9.0.4.0 - issues with jffi and ld.so.conf library paths; loads wrong libcrypt in lib32. see jruby/jruby#3409 - while we can work around assembling jruby by setting the ld config path, one would have to do this at runtime as well. not worth it. - this was fixed with a small patch that made it into 9.0.4.0 (so not a big deal to remove 9.0.3.0) [snap/#3050] Move rbenv installation in containers to $HOME (i.e. /var/go)
|
:( Seeing this trying to build the i386/alpine image of the docker jruby image. |
Not supporting i386+alpine yet since there seems to be an issue when installing bundler: related to jruby/jruby#3409 Signed-off-by: Brian Goff <cpuguy83@gmail.com>
I get the following exception if I try to install bundler with JRuby 9.0.3.0 on Ubuntu 14.04:
The text was updated successfully, but these errors were encountered: