Skip to content
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

java.library.path on Fedora #2016

Closed
eregon opened this Issue Oct 1, 2014 · 12 comments

Comments

Projects
None yet
5 participants
@eregon
Copy link
Member

commented Oct 1, 2014

Hello,

This seems similar to #1916. The error is always a variation of not loading class jnr.enxio.channels.Native$SingletonHolder.

$ mvn
[ERROR] Failed to execute goal io.tesla.polyglot:tesla-polyglot-maven-plugin:0.1.1:execute (install_gems) on project jruby-lib: Execution install_gems of goal io.tesla.polyglot:tesla-polyglot-maven-plugin:0.1.1:execute failed: java.lang.NoClassDefFoundError: Could not initialize class jnr.enxio.channels.Native$SingletonHolder

$ mvn -Pbootstrap
[INFO] --- gem-maven-plugin:1.0.5:initialize (default) @ jruby-tests ---
[WARNING] LoadError: load error: rubygems -- java.lang.NoClassDefFoundError: Could not initialize class jnr.enxio.channels.Native$SingletonHolder

For some cases, setting the java.library.path as below works but for mvn -Pbootstrap it fails.

export MAVEN_OPTS=-Djava.library.path=/usr/lib64
export JRUBY_OPTS=-J-Djava.library.path=/usr/lib64

I have no idea why Java would pick 32-bit libs since printing java.library.path from regular java (JLibPath) seems quite usual (there are 32-bit libs dirs at the end but the 64-bit versions should be preferred, no?):

/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib

Setting LD_LIBRARY_PATH does not seem to work although it has the effect of prepending the path for JLibPath (LD_LIBRARY_PATH_64 has no effect).

Would you have an idea how to solve this?


class JLibPath
{
    public static void main(String args[])
    {
        System.out.println(System.getProperty("java.library.path"));
    }
}
@chrisseaton

This comment has been minimized.

Copy link
Contributor

commented Oct 1, 2014

Do you get the same problem if you use a simple JDK tarball, rather than the packaged Java that Fedora supplies?

@eregon

This comment has been minimized.

Copy link
Member Author

commented Oct 1, 2014

I do have the same problem with an Oracle JDK, but it's hard to tell if it is used for everything although I did set JAVA_HOME, JAVACMD, alternatives, etc.

@eregon

This comment has been minimized.

Copy link
Member Author

commented Oct 1, 2014

I also experience the wrong ELF class: ELFCLASS32 and others things as mentioned in the JRuby Forum https://www.ruby-forum.com/topic/4416412.

@eregon

This comment has been minimized.

Copy link
Member Author

commented Oct 1, 2014

strace output if it can be of any help: https://gist.github.com/eregon/3c3c978fac737d497667
It seems a child (pid 30738) of the main process starts to use the 32-bit libc.

@mkristian

This comment has been minimized.

Copy link
Member

commented Oct 1, 2014

@eregon with mvm -Pbootstrap not picking the library path, you could try this mvn -Djruby.fork=false -P bootstrap. it will stays with the same jvm when installing gems.

@eregon

This comment has been minimized.

Copy link
Member Author

commented Oct 2, 2014

@mkristian That seems to work although the first run did produce some reflection error, thanks!

The fact the forked JVM picks the wrong libc sounds like a bug in the maven plugin.
And of course setting *_OPTS feels very hacky.

@mkristian

This comment has been minimized.

Copy link
Member

commented Oct 2, 2014

the maven plugin actually uses the ant java-task to fork since the ant task
does a lot of OS detection. but I just saw that the ant version used is
quite old and they changed quite a bit on how to execute a forked JVM. this
can be improved.

about the io.tesla.polyglot:tesla-polyglot-maven-plugin:0.1.1:execute
failing without setting the java.library.path seems more an jruby issue
since there it just picks a ScriptingContainer and execute some ruby code.

@headius

This comment has been minimized.

Copy link
Member

commented Nov 4, 2014

I have struggled with this on Fedora as well, and the only fix I found was forcibly setting java.library.path to only the 64-bit library directories. I'm still investigating why the paths are not set up properly.

@eregon

This comment has been minimized.

Copy link
Member Author

commented Nov 5, 2014

@headius How did you change java.library.path?
Using MAVEN_OPTS and JRUBY_OPTS as above?

@headius

This comment has been minimized.

Copy link
Member

commented Nov 6, 2014

@eregon Yes, that's what I did.

Another user ran into this and discovered that if he removed the 32-bit (i386) libc from his system, JRuby/JVM went back to finding the proper 64-bit lib. So one possible fix would be to let jffi/jnr-ffi exhaust all possible versions of the library found in LD_LIBRARY_PATH (and LD64_LIBRARY_PATH, if present).

@eregon

This comment has been minimized.

Copy link
Member Author

commented Nov 10, 2014

See jnr/jnr-ffi#29 which seeems the root of the problem.

@eregon

This comment has been minimized.

Copy link
Member Author

commented Nov 10, 2014

Fixed by jnr/jnr-ffi#29.

@eregon eregon closed this Nov 10, 2014

@enebo enebo added this to the JRuby 1.7.17 milestone Dec 8, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.