seems similar to a previous bug related to java. but the previous reporter was using an external stream whereas I am using the global tree. Seems to me that it is related to the new java system (recent evolutions of java-config and other stuffs) ../dist/../libdb_java/db_java_wrap.c:7295: error: syntax error before "void" ../dist/../libdb_java/db_java_wrap.c:7295: error: syntax error before '*' token ../dist/../libdb_java/db_java_wrap.c: In function `Java_com_sleepycat_db_db_1javaJNI_DbMpoolFile_1set_1maxsize': ../dist/../libdb_java/db_java_wrap.c:7297: error: `jlong' undeclared (first use in this function) ../dist/../libdb_java/db_java_wrap.c:7297: error: syntax error before "arg2" ../dist/../libdb_java/db_java_wrap.c:7300: error: `jenv' undeclared (first use in this function) ../dist/../libdb_java/db_java_wrap.c:7301: error: `jcls' undeclared (first use in this function) ../dist/../libdb_java/db_java_wrap.c:7302: error: `jarg1' undeclared (first use in this function) ../dist/../libdb_java/db_java_wrap.c:7303: error: `arg2' undeclared (first use in this function) ../dist/../libdb_java/db_java_wrap.c:7303: error: `jarg2' undeclared (first use in this function) make: *** [db_java_wrap.lo] Erreur 1 !!! ERROR: sys-libs/db-4.2.52_p2-r1 failed. Call stack: ebuild.sh, line 1543: Called dyn_compile ebuild.sh, line 938: Called src_compile db-4.2.52_p2-r1.ebuild, line 91: Called die !!! make failed !!! If you need support, post the topmost build error, and the call stack if relevant. [root@gui - 00:21:28 - ~] # emerge --info Portage 2.1.1_pre4-r3 (default-linux/x86/2006.0, gcc-3.4.6, glibc-2.3.6-r4, 2.6.17-gentoo-r4 i686) ================================================================= System uname: 2.6.17-gentoo-r4 i686 AMD Athlon(TM) MP 2400+ Gentoo Base System version 1.6.15 app-admin/eselect-compiler: [Not Present] dev-lang/python: 2.3.5-r2, 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i386-pc-linux-gnu" CFLAGS="-march=athlon-mp -O2 -pipe" CHOST="i386-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/splash /etc/terminfo" CXXFLAGS="-march=athlon-mp -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="fr_FR@euro" LC_ALL="fr_FR@euro" LINGUAS="fr" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/xgl-coffee /usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow 3dnowex 3dnowext X a52 aac acpi alsa apache2 apm arts artswrappersuid asf avi bash-completion berkdb bigger-fonts bindist bitmap-fonts bonobo bootsplash browserplugin bzip2 cairo calendar cdparanoia cdr chroot cli crypt cups curl dbus dga directfb divx4linux dlloader dri dv dvb dvd dvdr dvdread eds elibc_glibc emboss encode esd evo fam fbcon ffmpeg flac foomaticdb fortran gdbm ggi gif glitz gnome gphoto2 gpm gstreamer gtk gtk2 hal imap imlib input_devices_evdev input_devices_keyboard input_devices_mouse isdnlog jack java jbig jikes jpeg jpeg2k kde kdeenablefinal kdexdeltas kernel_linux kipi libg++ libwww linguas_fr lm_sensors logitech-mouse mad mikmod mmx mmxext mono motif mp3 mpeg nas ncurses nls nptl nvidia ogg oggvorbis opengl oss pam pcre pdf pdflib perl png pppd python qt qt3 qt4 quicktime readline real reflection ruby samba sdl session slp sndfile spell spl sse ssl svg svga tcltk tcpd theora tiff truetype truetype-fonts type1-fonts udev unicode usb userland_GNU video_cards_nv video_cards_nvidia vorbis win32codecs wmf x86 xml xml2 xmms xorg xosd xv xvid yaz zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS [root@gui - 00:23:30 - ~] # java-config-2 -L *) Sun JDK 1.5.0.07 [sun-jdk-1.5] (/usr/share/java-config-2/vm/sun-jdk-1.5)
Seems this ebuild doesn't inherit java-pkg eclass and instead tries to emulate its work itself... strange.
I think you've truncated the root error. Please post the full log. My guess without knowning anything else would be to say its related to JNI and includes for it. Maybe inheriting java-pkg, and calling java-pkg_pkg_setup during pkg_setup might help?
Created attachment 93573 [details] emerge log here you are
(In reply to comment #3) > Created an attachment (id=93573) [edit] > emerge log checking java version... 1.5.0_07 figures. As a workaround until it's fixed, you might try sourcing /etc/env.d/20java and then emerge. Assuming your generation-1 system vm is set properly...
Created attachment 93577 [details, diff] patch for the ebuild file Tried to fix it. Inherits java-pkg, calls java-pkg_pkg_setup if use java, removed the manual package.env creating, eclass handles that. Registers the jar, moves it to the right place, removing it from /usr/lib. Not sure about the java-pkg_doso part, it makes a copy of the .so file in /opt/db-4.2/, which might be bad. If it was generation-2 ebuild, I would use regso on the .so file already in /usr/lib/ but gen-1 java-pkg.eclass doesn't have it. Advice, nichoj? :)
* checking db-4.2.52.tar.gz ;-) ... [ ok ] * checking patch.4.2.52.1 ;-) ... [ ok ] * checking patch.4.2.52.2 ;-) ... [ ok ] * There was a problem determining which VM to use for generation-1 * You may need to set your generation-1 VM again, and run env-update && source/etc/profile * Also, make sure you have followed the Java Upgrade Guide: * http://www.gentoo.org/proj/en/java/java-upgrade.xml [ !! ] !!! ERROR: sys-libs/db-4.2.52_p2-r1 failed. Call stack: ebuild.sh, line 1559: Called dyn_setup ebuild.sh, line 666: Called pkg_setup db-4.2.52_p2-r1.ebuild, line 38: Called java-pkg_pkg_setup java-pkg.eclass, line 51: Called die !!! Expected VMHANDLE to be defined in the env, but it wasn't !!! If you need support, post the topmost build error, and the call stack if relevant. it is definitively linked to a generation-1 VM issue. I have opened an entry in the forum this morning (http://forums.gentoo.org/viewtopic-t-486890.html). Could you post an exemple of /etc/env.d/20java ? I don't have one
This means the patched ebuild is now working correctly and exposes the real problem you have. I'd say it's quite impossible to go through java upgrade guide correctly, and still have this problem. If anything, make sure you have latest java-config-wrapper (0.10-r3) and run java-check-environment, which should report errors and tell you what to do. It shouldn't pass with non-existing 20java... And I think you also have stale entries for java-config in your /etc/portage/package.unmask, so you're probably using the new testing package.masked revisions, giving you the python traceback.
My generation-1 VM was badly set up. Thanks for your help Caster ! (I explain the solving steps in http://forums.gentoo.org/viewtopic-t-486890.html )
(In reply to comment #8) > My generation-1 VM was badly set up. Thanks for your help Caster ! (I explain > the solving steps in http://forums.gentoo.org/viewtopic-t-486890.html > ) > You shouldn't close the bug until the ebuild (which _is_ wrong, too) is fixed. Please reopen and leave it up to devs.
leaving it up to the devs
This ebuild stems from the time that java-pkg wasn't there yet. I'll create a new bug for stabilizing this, and make this bug depend on it. In the meantime, either don't use unstable java or setup your old-style java.
The stabilizing bug is for ebuild inheriting generation 2 java system which is not stable yet (inherit java-pkg-opt-2), while my patch is to make this ebuild more properly use the stable generation-1 java system (inherit java-pkg), ensuring it works properly for people with mixed keywords. It is making it compatible with new system, not using (thus depending on) it and so the patched ebuild could be made stable immediately, while the generation 2 ebuild not.
The old ebuild has worked perfectly for a long time, and as long as you make sure that the javac portage finds is a 1.4 version nothing should go wrong. I looked at the eclass, but it still doesn't set the path so things will still go wrong if javac isn't set up correctly.
(In reply to comment #13) > The old ebuild has worked perfectly for a long time, and as long as you make > sure that the javac portage finds is a 1.4 version nothing should go wrong. I > looked at the eclass, but it still doesn't set the path so things will still go > wrong if javac isn't set up correctly. > I'm sorry, you're right it sets only JAVA_HOME, not JAVAC. The patch could be extended to call $(java-config --javac) though, after the env is initialized by java-pkg_pkg_setup. But it's true that as long as JAVAC is good in the env (and it should be, even with new system), current ebuild will work too. The reporter had it broken, my patch at least helped to recognize it, but it was still his fault. So I guess leaving it as it is is fine.
(In reply to comment #13) > The old ebuild has worked perfectly for a long time, and as long as you make > sure that the javac portage finds is a 1.4 version nothing should go wrong. I > looked at the eclass, but it still doesn't set the path so things will still go > wrong if javac isn't set up correctly. > While it doesn't set the path, inheriting the eclass and using its pkg_setup does ensure that the Java setuff is properly set... For example, with the new Java stuff, /usr/bin/javac would be what is found. Without doing java-pkg_pkg-setup, /usr/bin/javac would end up using the generation-2 system vm, which may or may not be 1.4. By inherinting the eclass, GENTOO_VM gets set to the generation-1 system vm, and /usr/bin/javac will end up using that. So please, consider applying the fix proposed by Caster. You could leave off the bit about using dojar instead of creating the package.env yourself, as it wouldn't affect anything.
Created attachment 95515 [details, diff] updated patch for the ebuild file I've updated the patch to also set JAVAC because configure relies on that and not JAVA_HOME (java-pkg_pkg_setup in eclass sets only JAVA_HOME, setting JAVAC too wouldn't hurt probably). I've left the package.env stuff alone. - On purely stable system java-pkg_pkg_setup determines there's no gen-2 support and doesn't set anything. All PATH and JAVA_HOME should be already in the env, my extra JAVAC assignment should only set it to what already should be there (i.e. also do nothing). - On system with mixed keywords, java-pkg_pkg_setup sets JAVA_HOME and GENTOO_VM in a way that the JAVAC assigmnent puts gen-1 system vm JAVAC there. This is the output on configure on mixed keywords system. It builds fine to the end. checking if /opt/sun-jdk-1.4.2.12/bin/javac works... yes checking for jar... jar checking for java... java checking for uudecode... no configure: WARNING: I have to compile Test.class from scratch checking if java works... yes checking for /opt/sun-jdk-1.4.2.12/bin/javac... /opt/sun-jdk-1.4.2.12/bin/javac checking absolute path of /opt/sun-jdk-1.4.2.12/bin/javac... /opt/sun-jdk-1.4.2.12/bin/javac checking java version... 1.4.2_12
Eclass now sets JAVAC itself (to fix bug 145632), so the patch can be trimmed down to adding java-pkg to inherit, and the pkg_setup thing.
db-4.2.52_p4-r2 has been stabilized on all archs that we support Java on. Marking fixed.
