-
-
Notifications
You must be signed in to change notification settings - Fork 925
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
JRuby fails in building from source when using openjdk-7-jdk trusty package #4103
Comments
It seems like the complete log was truncated, or else the bits I need didn't get in there. Can you do another attempt without -X and gist that too? We do build with Java 7 periodically, so that shouldn't be the issue. Unfortunately I can't see the actual error. |
@RochesterinNYC are you sure it works with 7u111-2.6.7-0ubuntu0.14.04.2 as it is only two days older then 7u111-2.6.7-0ubuntu0.14.04.3 but has some mentioning of 'unsafe' with it - these two unsafe methods could be the cause of the failure. to the see the compilation error it shold help to add |
I think the full log output is available here: https://gist.githubusercontent.com/RochesterinNYC/fac1f36bb98ded1f5a135f10b2c8741c/raw/ec88989ef61a62fe4aca23030b482113720d2b73/compile.log We feel that it works with |
Hm, additionally, we're having some trouble trying to build with The specified "fork=false" shows up in the logs if you search for them, but fork is ultimately set as "fork = true". |
@RochesterinNYC ok I can reproduce the error with your Docker setup. can you give me some hints on how I can find the output and how to maybe run maven manually ? bit lost in the filestructure in /binary-builder |
It shouldn't be too difficult to take that last javac command line and run it. It's the line starting with Ideally, that will show us why the javac step is blowing up. I sure hate Maven for hiding the actual error. |
@headius the error I see is:
|
so I missed the bootclasspath and this line could be the problem:
i.e. maven can not resolve why is thie |
@mkristian So it's not picking up our bootstrap unsafe mock then I guess? |
@mkristian The -J is because it's being passed to javac. |
@headius so I am confused as if I change the core/pom.rb to use |
@mkristian I feel like we've had this discussion before...now I'm confused too. |
@headius both seems to valid if I look at |
Is anything needed from us in terms of reproducibility or debug logs? |
@RochesterinNYC I can reproduce the error and I have a workaround. not sure why things changed with jdk version. will produce a PR and let the jruby core team decide if they want to go with it. |
Hello, We're not sure that this fixes our problem. We tried to build JRuby 9.1.3.0 in the manner described above, however the build still fails. The command we ran in our container:
In the logs, we saw that -Xbootclasspath was passed to the java compiler:
|
@sesmith177 Well that's frustrating :-( I'm not sure what else would be causing a problem. Can you try removing all bootclasspath lines from the compile plugins (use @mkristian's patch as a guide) and see if we at least get a reasonable error? For background: the unsafe-mock library was added so we could compile code that uses There must be a way to get more information out of that blasted compiler plugin! |
Reopened and targeted to 9.1.5.0. |
Ok, so this appears to be something other than the bootclasspath failing. One more thing to try: just remove the -J version of that flag. I'm wondering if forcing our Unsafe into the underlying JVM is breaking javac, where the plain -X version would not have that effect. |
@headius Removing the |
I was sure I got it to work before I suggested a patch for our build. well, did not test the patch on the docker container :( still think we can use maven profiles to the bootclasspath for the different jdks the right way. have to play around with this. |
For context, the way I've been making these jruby source edits and playing around is once you boot up the container and execute a failed build of jruby, the jruby source tarball will be at |
Of course it did! 😞 I wonder if we could fudge this with method handles and eliminate the mocks. What a pain. |
One other thing did occur to me...we are backing off from forcing instance variables to be volatile in favor of an explicit API. So that would reduce our need for the Java 8+ fence methods on Unsafe. I also did a quick benchmark of a MethodHandle-based fullFence that doesn't require a mock, and it ends up with basically the same performance as calling Unsafe directly. Pretty impressive. |
Are there any other testing or logs or things you'd want us to try to provide feedback/info? |
jdk9 on macos can not handle both configurations. is related to #4103
I think this requires heavier lifting on our side, like moving both the unsafe mock usage AND the utility library wrapped around it to a separate library, so we can build it however we please without affecting the JRuby codebase. That's not going to happen for 9.1.6.0 but it could happen for 9.1.7.0. Then we could just drop the pesky bootclasspath flag entirely. |
@headius thanks for the update. Please keep us involved and let us know if there's anything the CF Buildpacks Team can do. |
jdk9 on macos can not handle both configurations. is related to #4103
jdk9 on macos can not handle both configurations. is related to #4103
This commit replaces the unsafe-mock dependency -- which caused various build problems living in boot classpath -- with a new library that just shims the three Unsafe methods added in Java 8: fullFence, loadFence, and storeFence. This allows us to eliminate all calls to those methods from JRuby proper as well as the build tricks. Fixes jruby#4103.
This commit replaces the unsafe-mock dependency -- which caused various build problems living in boot classpath -- with a new library that just shims the three Unsafe methods added in Java 8: fullFence, loadFence, and storeFence. This allows us to eliminate all calls to those methods from JRuby proper as well as the build tricks. Fixes jruby#4103.
This commit replaces the unsafe-mock dependency -- which caused various build problems living in boot classpath -- with a new library that just shims the three Unsafe methods added in Java 8: fullFence, loadFence, and storeFence. This allows us to eliminate all calls to those methods from JRuby proper as well as the build tricks. Fixes jruby#4103.
Environment
Provide at least:
9.1.2.0
from sourceuname -a
:Linux d64e610fc91e 4.4.16-boot2docker #1 SMP Fri Jul 29 00:13:24 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Expected Behavior
7u111-2.6.7-0ubuntu0.14.04.3
of the ubuntu trusty openjdk-7-jdk package.Actual Behavior
7u111-2.6.7-0ubuntu0.14.04.3
of the ubuntu trusty openjdk-7-jdk package.Reproduction:
The full error log after switching maven to try and build jruby with the
-X
flag enabled is here: https://gist.github.com/RochesterinNYC/fac1f36bb98ded1f5a135f10b2c8741cBinary builder will try to install openjdk via apt-get, build and compile ant and maven, and then use maven to try to build jruby. It runs the following command to try to build jruby:
mvn -Djruby.default.ruby.version=2.3.0
Side Note:
It might be worth noting that for our situation, this build process was working when we were on openjdk-7-jdk
7u111-2.6.7-0ubuntu0.14.04.2
. When openjdk-7-jdk7u111-2.6.7-0ubuntu0.14.04.3
was released on August 11th, our build process automatically started using this (because we useapt-get install
) and the build started failing.The text was updated successfully, but these errors were encountered: