| Summary: | sci-libs/opencascade[java] - ERROR: Couldn't find a VM dep | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Juergen Rose <rose> |
| Component: | [OLD] Library | Assignee: | Michael Weber (RETIRED) <xmw> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | blackhack, dirk, fatzer2, gentoo, gustav.schaffter, jouni.kosonen, msulli1355, randy-andy-, richard.kenney, rossi.f, ulm |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | build.log | ||
|
Description
Juergen Rose
2015-02-28 14:06:27 UTC
Same here. This seems to be related by this change:
- java? ( >=virtual/jdk-0 )
+ java? ( virtual/jdk:= )
as the older versions now give the same error after that change.
Using
java? ( >=virtual/jdk-0:= )
seems to work, but I'm less that crystal clear how the slot dependencies work with depend-java-query.
Same problem here. GENTOO_VM= CLASSPATH="" JAVA_HOME="" JAVACFLAGS="" COMPILER="" #java-config --list-available-vms The following VMs are available for generation-2: *) IcedTea JDK 7.2.5.3 [icedtea-bin-7] I verified that IcedTea is active. #java-config -f icedtea-bin-7 Any news? (In reply to Juergen Rose from comment #3) > Any news? Since yesterday there is a new opencascade-6.8.0.ebuild in the portage tree, but 'emerge opencascade' fails with the same error. opencascade-6.8.0 still fails to emerge with the same error. The patch of Comment 1 works. It would be very nice, if someone could add the patch to default portage tree. The reason it fails is that /usr/bin/depend-java-query (part of dev-java/java-config) can't handle the string "virtual/jdk:=". e.g. /usr/bin/depend-java-query --get-vm "virtual/jdk:=" I see two ways to resolve it: The first one is to use ">=virtual/jdk-0:=" instead of the current variant. The second one is to patch the java-config to make it recognize more versions. IMO the first one can be done immidiately and as a long-term enhancement the second one can be done a bit later. I filled in a different bug about the second resolution: Bug 547898. The change that was made doesn't make sense, see my comment in bug #547898. I haven't got time right now to find out exactly how this package uses Java but I suspect it strays from the norm. When building any Java software under Gentoo, you're supposed to set the minimum -source and -target flags to ensure that the software will run on more than just the VM you built it with. Java VMs are highly backwards compatible and there's no need to have a restriction like :=. Yes! https://bugs.gentoo.org/show_bug.cgi?id=541644#c1 "Comment 1" its work. im use gentoo at home, and 2 days (nights ;-) trying install opencascade use "java" flag for freecad. step 1 - install full version java-vm (icedtea-7 - upon 8core -very very long time) step 2 set correct java-conf-path (see java gentoo,etc) step 3 correct file /usr/portage/sci-libs/opencascade/opencascade-6.8.0.ebuild : correct string " java? ( >=virtual/jdk-0:= )" step 4 ebuild /usr/portage/sci-libs/opencascade/opencascade-6.8.0.ebuild manifest step 5 install eselect-opencascade step 6 eselect opencascade set (you version) - generate /etc/env.d/51opencascade step 7 - chek changes - emerge opencascade. if you succed - you can create self-local portage (layman,etc.) for protect changes "emerge --sync" (In reply to James Le Cuirot from comment #7) > When building any Java software under > Gentoo, you're supposed to set the minimum -source and -target flags to > ensure that the software will run on more than just the VM you built it > with. Java VMs are highly backwards compatible and there's no need to have a > restriction like :=. The dependency is not for a JRE, it's for the location of Java native development headers (jni.h, jni_md.h) from a JDK needed to build a JNI proxy library written in c++. Since the test is for a JNI >= 1.2, I don't know if the library really needs to be rebuilt when the system vm is changed to a different slot. I'm not even sure if the library gets built at all when not compiling for an Android environment (see http://dev.opencascade.org/doc/overview/html/samples_java_android_occt.html ) If the proxy library is the only user of the JNI headers and it isn't even built, the whole USE flag and virtual/jvm dependency could just as well be dropped and "--without-java-include" hard-wired into the configuration. May be someone will just fix the wrong dependence to get working ebuild rather than arguing whether to drop it or if it should be rebuilded with java or not? Sorry for my perseverance and impatience... It still fails:
root@orca:/root(26)# java-config -L
The following VMs are available for generation-2:
1) IcedTea JDK 6.1.13.7 [icedtea-6]
*) IcedTea JDK 7.2.5.5 [icedtea-7]
root@orca:/root(27)# emerge --update --newuse --deep --with-bdeps=y --backtrack=30 @world
Calculating dependencies... done!
[ebuild NS ] sci-libs/opencascade-6.8.0 [6.7.1] USE="doc examples java qt4 tbb -debug -freeimage -gl2ps"
...
>>> Emerging (1 of 1) sci-libs/opencascade-6.8.0::gentoo
* opencascade-6.8.0.tgz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ]
* Checking for at least 256 MiB RAM ... [ ok ]
* Checking for at least 3584 MiB disk space at "/var/tmp/portage/sci-libs/opencascade-6.8.0/temp" ... [ ok ]
!!! ERROR: Couldn't find a VM dep
* Unable to determine VM for building from dependencies:
NV_DEPEND: app-eselect/eselect-opencascade
dev-lang/tcl:0=
dev-lang/tk:0=
dev-tcltk/itcl
dev-tcltk/itk
dev-tcltk/tix
media-libs/ftgl
virtual/glu
virtual/opengl
x11-libs/libXmu
freeimage? ( media-libs/freeimage )
gl2ps? ( x11-libs/gl2ps )
java? ( virtual/jdk:= )
tbb? ( dev-cpp/tbb ) !<sys-devel/gettext-0.18.1.1-r3
|| ( >=sys-devel/automake-1.14.1:1.14 >=sys-devel/automake-1.15:1.15 )
>=sys-devel/autoconf-2.69
>=sys-devel/libtool-2.4 java? ( >=dev-java/java-config-2.2.0 )
* ERROR: sci-libs/opencascade-6.8.0::gentoo failed (setup phase):
* Failed to determine VM for building.
*** Bug 555644 has been marked as a duplicate of this bug. *** Same here with the newest version from Today tree syncing: * Package: sci-libs/opencascade-6.9.0 * Repository: gentoo * Maintainer: xmw@gentoo.org * USE: abi_x86_64 amd64 elibc_glibc java kernel_linux qt4 tbb userland_GNU * FEATURES: preserve-libs sandbox userpriv usersandbox * Checking for at least 256 MiB RAM ... [ ok ] * Checking for at least 3584 MiB disk space at "/var/tmp/portage/sci-libs/opencascade-6.9.0/temp" ... [ ok ] !!! ERROR: Couldn't find a VM dep * Unable to determine VM for building from dependencies: NV_DEPEND: app-eselect/eselect-opencascade dev-lang/tcl:0= dev-lang/tk:0= dev-tcltk/itcl dev-tcltk/itk dev-tcltk/tix media-libs/ftgl virtual/glu virtual/opengl x11-libs/libXmu freeimage? ( media-libs/freeimage ) gl2ps? ( x11-libs/gl2ps ) java? ( virtual/jdk:= ) tbb? ( dev-cpp/tbb ) !<sys-devel/gettext-0.18.1.1-r3 || ( >=sys-devel/automake-1.15:1.15 ) >=sys-devel/autoconf-2.69 >=sys-devel/libtool-2.4 java? ( >=dev-java/java-config-2.2.0 ) * ERROR: sci-libs/opencascade-6.9.0::gentoo failed (setup phase): * Failed to determine VM for building. * * Call stack: * ebuild.sh, line 93: Called pkg_setup * opencascade-6.9.0.ebuild, line 43: Called java-pkg-opt-2_pkg_setup * java-pkg-opt-2.eclass, line 48: Called java-pkg_init * java-utils-2.eclass, line 2138: Called java-pkg_switch-vm * java-utils-2.eclass, line 2608: Called die * The specific snippet of code: * die "Failed to determine VM for building." * * If you need support, post the output of `emerge --info '=sci-libs/opencascade-6.9.0::gentoo'`, * the complete build log and the output of `emerge -pqv '=sci-libs/opencascade-6.9.0::gentoo'`. !!! When you file a bug report, please include the following information: GENTOO_VM= CLASSPATH="" JAVA_HOME="" JAVACFLAGS="" COMPILER="" and of course, the output of emerge --info =opencascade-6.9.0 * The complete build log is located at '/var/tmp/portage/sci-libs/opencascade-6.9.0/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sci-libs/opencascade-6.9.0/temp/die.env'. * Working directory: '/usr/lib64/python2.7/site-packages' * S: '/var/tmp/portage/sci-libs/opencascade-6.9.0/work/opencascade-6.9.0' /var/tmp/portage/sci-libs/opencascade-6.9.0/temp/build.log lines 1-50/50 (END) opencascade-6.9.0 can be emerged with the patch of Comment 1. But I did not understand the discussion of Comment 6-9. Is it legitim to use this patch or not? (In reply to Juergen Rose from comment #14) > opencascade-6.9.0 can be emerged with the patch of Comment 1. But I did not > understand the discussion of Comment 6-9. Is it legitim to use this patch or > not? I've proposed to patch java-config rather than applying the patch to the ebuild. And it was declined. As I understood James agreed that the line in the ebuild which triggers the bug is wrong and the patch from comment #1 or #6 will make the ebuild work, but it's still arguable what should really must be in place of that line. So "the patch is ok but may be better". commit 410d3a68e98a87f63e117175a506fd292134f865 Author: Michael Weber <xmw@gentoo.org> Date: Sun Aug 23 13:15:09 2015 +0200 sci-libs/opencascade: Fix USE=java dep to >=virtual/jdk-0:= (thanks to all contributors on bug 541644). Package-Manager: portage-2.2.20.1 sci-libs/opencascade/opencascade-6.7.1.ebuild sci-libs/opencascade/opencascade-6.8.0.ebuild sci-libs/opencascade/opencascade-6.9.0.ebuild |
