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
Closed

java.library.path on Fedora #2016

eregon opened this issue Oct 1, 2014 · 12 comments
Milestone

Comments

@eregon
Copy link
Member

@eregon eregon 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
Copy link
Contributor

@chrisseaton chrisseaton 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
Copy link
Member Author

@eregon eregon 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
Copy link
Member Author

@eregon eregon 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
Copy link
Member Author

@eregon eregon 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
Copy link
Member

@mkristian mkristian 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
Copy link
Member Author

@eregon eregon 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
Copy link
Member

@mkristian mkristian 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
Copy link
Member

@headius headius 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
Copy link
Member Author

@eregon eregon commented Nov 5, 2014

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

@headius
Copy link
Member

@headius headius 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
Copy link
Member Author

@eregon eregon commented Nov 10, 2014

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

@eregon
Copy link
Member Author

@eregon eregon 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
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants