Created attachment 376760 [details] emerge info for jruby-1.6.8-r1 with emerge rubygems the first package to be installed is jruby which wont compile .Hence ruby isn't installed.
Created attachment 376762 [details] build log for jruby
Created attachment 376764 [details] environment file
(In reply to Geoff Madden from comment #0) > with emerge rubygems the first package to be installed is jruby which wont > compile .Hence ruby isn't installed. This should only happen when you have explicitly listed jruby in your RUBY_TARGETS (in /etc/portage/make.conf).
(In reply to Hans de Graaff from comment #3) > This should only happen when you have explicitly listed jruby in your > RUBY_TARGETS (in /etc/portage/make.conf). According to your emerge --info you don't have this. What exactly are you trying to emerge, and with which package manager? Also, which jdk do you have installed?
(In reply to Hans de Graaff from comment #4) > What exactly are you trying to emerge, and with which package manager? According to the Description; Portage and rubygems, with `emerge rubygems`. > Also, which jdk do you have installed? According to the build log, oracle-jdk-bin-1.8.0.5. A search yields http://ant.1045680.n5.nabble.com/Java8-and-APT-td5714777.html which seems to suggest that apt and associated API (com.sun.mirror.apt) are to be removed in a major JDK release, in other words, Oracle JDK 1.8; I suppose the story is similar for the other errors. Testing this; it works on Oracle JDK 1.7, but breaks on Oracle JDK 1.8. (In reply to Hans de Graaff from comment #3) > This should only happen when you have explicitly listed jruby in your > RUBY_TARGETS (in /etc/portage/make.conf). Yeah, this is odd; `emerge -pv --tree --unordered-display rubygems` could tell.
Created attachment 376808 [details] results of -pv --tree
I'll give it a try again with just rubygems this time
HMMMM might have been more complicated by the fact that ruby 21 wasn't installed. I installed the oraclejdk 7u55 and set that as the VM then ran emerge ruby,which installed 21,& although jruby installed ok there were a heap of error msg's about missing definitions,but these were apparantly ignored,and jruby completed successfully in 1m. Not able to show the errors as things were cleared up after install.
Also jruby appeared to be looking for jdk1.5 according to the elog
ERROR: dev-java/jruby-1.6.8-r1::gentoo failed (compile phase): eant failed Call stack: ebuild.sh, line 93: Called src_compile environment, line 3964: Called eant 'jar' '-Djdk1.5+=true' '-Dgenerate-ri-cache.hasrun=true' environment, line 648: Called die The specific snippet of code: ant ${antflags} "${@}" || die "eant failed" If you need support, post the output of `emerge --info '=dev-java/jruby-1.6.8-r1::gentoo'`, the complete build log and the output of `emerge -pqv '=dev-java/jruby-1.6.8-r1::gentoo'`. The complete build log is located at '/var/tmp/portage/dev-java/jruby-1.6.8-r1/temp/build.log'. The ebuild environment file is located at '/var/tmp/portage/dev-java/jruby-1.6.8-r1/temp/environment'. Working directory: '/var/tmp/portage/dev-java/jruby-1.6.8-r1/work/jruby-1.6.8' S: '/var/tmp/portage/dev-java/jruby-1.6.8-r1/work/jruby-1.6.8'
(In reply to Tom Wijsman (TomWij) from comment #5) > A search yields http://ant.1045680.n5.nabble.com/Java8-and-APT-td5714777.html > which seems to suggest that apt and associated API (com.sun.mirror.apt) are > to be removed in a major JDK release, in other words, Oracle JDK 1.8; I > suppose the story is similar for the other errors. That was also my conclusion when I did some searching yesterday. I've updated the jruby 1.6 ebuild to depend on <virtual/jre-1.8 and <virtual/jdk-1.8 to reflect this. Given that we are trying to get rid of jruby 1.6 I don't think we need to look at additional fixes for this.
(In reply to Geoff Madden from comment #8) > a heap of error msg's about missing definitions This is probably the javadoc compilation, where these can be safely ignored; I'm not sure why it is throwing these, or whether there is a way to mute them. (In reply to Hans de Graaff from comment #11) > Given that we are trying to get rid of jruby 1.6 I don't think we need to > look at additional fixes for this. True, though note that jruby 1.7 supports >=virtual/jdk-1.8 only at the moment; whether that can be made to work with >=virtual/jdk-1.7, I have no idea...
