Gentoo: Unable to determine VM for building from dependencies

After summer vacations I decided it was high time to freshen up the gentoo systems (all of them are x86_64 arch - remind me one day to write some about the home network :-) ). Well after some 200+ packages marked for build I sat back and continued with my writing assignment…

After12 hours or so, on package number #144/222 namely xulrunner a strange error appeared… It was definately saying that the system could not determine the java VM to build the stupid xulrunner… Damn it I said and typed

GEN64-1 ~ # eselect java-vm list
Available Java Virtual Machines:
[1] blackdown-jdk-1.4.2
[2] emul-linux-x86-java-1.6
[3] sun-jdk-1.6 system-vm
GEN64-1 ~ #

Obviusly I had the original Java correctly installed. A python glitch I thought and then decided to check whether it was a sun’s java problem…

#eselect java-vm set system 1

A long story told short at every java configuration change the # emerge --resume responded the same way;

* Unable to determine VM for building from dependencies:
*
* ERROR: net-libs/xulrunner-1.8.1.16 failed.
* Call stack:
* ebuild.sh, line 49: Called pkg_setup
* xulrunner-1.8.1.16.ebuild, line 51: Called java-pkg-opt-2_pkg_setup
* java-pkg-opt-2.eclass, line 44: Called java-pkg_init
* java-utils-2.eclass, line 2090: Called java-pkg_switch-vm
* java-utils-2.eclass, line 2516: Called die
* The specific snippet of code:
* die "Failed to determine VM for building."
* The die message:
* Failed to determine VM for building.

At the beginning I thought “screw java lets skip its USE flag” (in the /etc/portage/package.use file) but afterwards I realized that this idea was quite stupid (why this holds smart reader?)
I decided that the ebuild was ok since I had already compiled xulrunner from the same sources in another system at the same period of time. So it was unfortunately time for debug… After a few debug conditions at the ebuild strange things happend from simple python statements… In fact I thought that something was terribly wrong with python. At the moment I thought it was some kind of revenge for all the bad things I have said about python but no… Shit happends I guessed and took a look at python #eix python
Then it hit me… I had upgraded from python 2.4 to 2.5……… So after a #python-update (and lots of compilations - thank God that ccache and distcc does speed up with this #@$(#_!@# ) everything worked as a charm…
So remember, if strange unexpected glitches occures, maybe its python’s fault…

GG python

2 comments so far

Had the same problem, had to re emerge java-config

Jason
September 23rd, 2008 at 4:59 am

indeed this seems to be the source of the problems. In my case java-config was also selected by the python system updater.

In a fragmented environment though where python has been under a drastic change this course of action leaves alot of issues unattended (many packages affected by the python change should be also “corrected”) and that’s why the proposed way is the python updater…

in the other hand one could just skip the entire gentoo philosophy (the way packages handle env variables) and directly change the JAVAC, JAVA_HOME, and JDK_HOME env variables and xulrunner should also be able to compile (tested!) but the point is to provide with the most orthodox way :-P

thanks for the tip though :-)

korki
September 25th, 2008 at 8:51 am

Leave a Comment

Name (required)

Mail (will not be published) (required)

Website

Comment