When building =app-office/openoffice-3.0.0 on amd64 with USE="cups dbus java kde ldap linguas_de nsplugin odk opengl pam", on amd64 the build finally fails with the error messages ERROR: error 65280 occurred while making /var/tmp/portage/app-office/openoffice-3.0.0/work/ooo/build/ooo300-m9/wizards/com/sun/star/wizards/reportbuilder ERROR: error 65280 occurred while making /var/tmp/portage/app-office/openoffice-3.0.0/work/ooo/build/ooo300-m9/xmerge/source/htmlsoff (see attachments for the full error log) Reproducible: Always Steps to Reproduce: 1.emerge =app-office/openoffice-3.0.0 [= the currently stable version] Actual Results: [... previous lines omitted ...] ------------- echo . > ../unxlngx6.pro/misc/linkinc.ls Running processes: 0 deliver -- version: 1.130 Module 'sc' delivered successfully. 170 files copied, 6 files unchanged 2 module(s): xmerge wizards need(s) to be rebuilt Reason(s): ERROR: error 65280 occurred while making /var/tmp/portage/app-office/openoffice-3.0.0/work/ooo/build/ooo300-m9/wizards/com/sun/star/wizards/reportbuilder * Build failed * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/log/ebuilds/app-office:openoffice-3.0.0:20090425-194028.log'. * The ebuild environment file is located at '/var/tmp/portage/app-office/openoffice-3.0.0/temp/environment'. * !!! When you file a bug report, please include the following information: GENTOO_VM=sun-jdk-1.6 CLASSPATH="" JAVA_HOME="/opt/sun-jdk-1.6.0.13" JAVACFLAGS="-source 1.5 -target 1.5" COMPILER="" and of course, the output of emerge --info >>> Failed to emerge app-office/openoffice-3.0.0, Log file: >>> '/var/log/ebuilds/app-office:openoffice-3.0.0:20090425-194028.log' !!! When you file a bug report, please include the following information: GENTOO_VM=sun-jdk-1.6 CLASSPATH="" JAVA_HOME="/opt/sun-jdk-1.6.0.13" JAVACFLAGS="-source 1.5 -target 1.5" COMPILER="" Could the problem be related to my use of the "odk" USE flag? I am assuming not too many people build their OOO with that USE flag set (or build it at all rather than using the binary version), so perhaps it might not have been tested at all on amd64?
Created attachment 189432 [details] Build log Original path name was: /var/log/ebuilds/app-office:openoffice-3.0.0:20090425-194028.log File has been LZMA-packed because of its size.
Created attachment 189433 [details] The effective build environment variables Original path name was: /var/tmp/portage/app-office/openoffice-3.0.0/temp/environment File has been LZMA-compressed because of its size.
The output of emerge --info on the build machine: Portage 2.1.6.7 (default/linux/amd64/2008.0/desktop, gcc-4.3.2, glibc-2.8_p20080602-r1, 2.6.27-gentoo-r8-xquad-9.27 x86_64) ================================================================= System uname: Linux-2.6.27-gentoo-r8-xquad-9.27-x86_64-AMD_Phenom-tm-_9600_Quad-Core_Processor-with-glibc2.2.5 Timestamp of tree: Sat, 25 Apr 2009 14:45:02 +0000 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.4 [enabled] app-shells/bash: 3.2_p39 dev-java/java-config: 2.1.7 dev-lang/python: 2.5.4-r2 dev-python/pycrypto: 2.0.1-r8 dev-util/ccache: 2.4-r7 dev-util/cmake: 2.6.2-r1 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O2 -DNDEBUG -pipe -fno-stack-check" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/local/etc /usr/share/X11/xkb /usr/share/config /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/host-variants/ /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-march=k8 -O2 -DNDEBUG -pipe -fno-stack-check" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--nospinner --with-bdeps=y" FEATURES="ccache distlocks fixpackages notitles prelink protect-owned sandbox sfperms strict unmerge-orphans userfetch userpriv usersandbox" GENTOO_MIRRORS="http://lug.mtu.edu/gentoo/ ftp://gentoo.mirrors.tds.net/gentoo http://gentoo.mirrors.tds.net/gentoo http://gentoo.chem.wisc.edu/gentoo/ http://gentoo-euetib.upc.es/mirror/gentoo/ ftp://gentoo.chem.wisc.edu/gentoo/ ftp://distro.ibiblio.org/pub/linux/distributions/gentoo/ ftp://gentoo.in.th/ http://ftp.twaren.net/Linux/Gentoo/ ftp://ftp.twaren.net/Linux/Gentoo/" LANG="de_AT.utf8" LDFLAGS="-Wl,-O1" LINGUAS="de" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_COMPRESS="lzma" PORTAGE_COMPRESS_FLAGS="-9" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/mscgen /usr/portage/local/layman/xworld /usr/portage/local/layman/simplux /usr/portage/local/layman/xworld_attic /usr/portage/local/layman/xworld_serviced /usr/portage/local/layman/xworld_hotfixes /usr/portage/local/layman/xworld_thirdparty /usr/portage/local/overlay" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="3dnow 3dnowext X a52 aac aalib acpi alsa amd64 apache2 arts aspell audiofile bash-completion berkdb branding bzip2 cairo caps cddb cdr cleartype cli cracklib crypt css cups curl custom-cflags custom-cxxflags dbus dri dts dv dvd dvdr dvdread ecc emboss encode evo exif expat ffmpeg fftw firefox flac foomaticdb fortran freetype ftp fuse gd gdbm gif gimp glade glut gmp gphoto2 gpm gtk gtk2 hal iconv idea ieee1394 imagemagick imlib isdnlog jack java6 javascript jbig jp2 jpeg jpeg2k kde kdeenablefinal kdehiddenvisibility kdexdeltas kipi kpathsea lame lcms ldap libcaca libclamav libnotify libsamplerate logrotate lzma lzo mad matroska midi mikmod mmap mmx mmxext mng mp3 mpeg mudflap mule multilib musepack musicbrainz ncurses nls nodrm nptl nptlonly nsplugin oav ocamlopt odbc offensive ofx ogg openal opengl openmp pam pcre pdf perl pic png ppds pppd pulseaudio python qt qt3 qt3support qt4 quicktime readline reflection samba sasl screen sdl session sharedmem slang smartcard sndfile sox speex spell spl sqlite sse sse2 sse3 sse4a ssl startup-notification svg sysfs tcltk tetex theora threads threadsafe tiff tk truetype unicode usb userlocales utf8 vcd vde vorbis wxwindows x264 xft xml xorg xosd xpm xrandr xscreensaver xsl xulrunner xv xvid xvmc zlib" ALSA_CARDS="emu10k1" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev joystick keyboard mouse void" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de" USERLAND="GNU" VIDEO_CARDS="dummy radeon v4l vesa vga" Unset: CPPFLAGS, CTARGET, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_RSYNC_EXTRA_OPTS
As of this date, I have not yet deleted the contents of the build directory. If any directory listing or file contents may be of interest for analyzing the problem, just let me know and I will be happy to upload it as an attachment.
Could there be a connection with bug 267548 ? When I run $ java-check-environment it complains I have no generation-1 VM installed - which is absolutely true. And I actually do *not* want to install one either! According to 'equery depend', none of my installed ebuilds need jdk-1.4 or less, including OOO. But is that true? Perhaps OOO *does* require a generation-1 VM, and the dependency information in the ebuild is incomplete? That might explain why a component like the report builder fails building, because I suspect it might be written in JAVA (and perhaps it requires jdk 1.4). Actually, I wonder why a "reportbuilder" is built at all: I always thought that would be an external add-on component to be installed. Or is that "reportbuilder" component not the same as the "Sun Report Builder" which can be found on the OOO extensions web-site?
Some other thing that worries me is the JAVACFLAGS="-source 1.5 -target 1.5" diagnostic message: I do not have jdk-1.5 installed at all - just jdk-1.6! Where does that "1.5" come from? I could only find a file /etc/env.d/20java-config but it just contains MANPATH=/etc/java-config/system-vm/man/ CONFIG_PROTECT_MASK="/etc/env.d/java/" so there is no evident reference to a 1.5 VM at all.
I just ran $ java-config -rOo /opt/sun-jdk-1.6.0.13/jre/lib/resources.jar:/opt/sun-jdk-1.6.0.13/jre/lib/rt.jar:/opt/sun-jdk-1.6.0.13/jre/lib/jsse.jar:/opt/sun-jdk-1.6.0.13/jre/lib/jce.jar:/opt/sun-jdk-1.6.0.13/jre/lib/charsets.jar /opt/sun-jdk-1.6.0.13 /opt/sun-jdk-1.6.0.13 - still no reference to some jdk-1.5 or jre-1.5. $ java-config -L The following VMs are available for generation-2: *) Sun JDK 1.6.0.13 [sun-jdk-1.6] Still no clue. $ java-config -l [servletapi-2.4] Servlet API 2.4 from jakarta.apache.org (/usr/share/servletapi-2.4/package.env) [ant-core] Java-based build tool similar to 'make' that uses XML configuration files. (/usr/share/ant-core/package.env) [servlet-api-2.3] Tomcat's Servlet API 2.3/JSP API 1.2 implementation (/usr/share/java-config-2/virtuals/servlet-api-2.3) [sac] SAC is a standard interface for CSS parser (/usr/share/sac/package.env) [jdbc-postgresql] JDBC Driver for PostgreSQL (/usr/share/jdbc-postgresql/package.env) [flute] Flute is an implementation for SAC (/usr/share/flute/package.env) [openoffice] OpenOffice.org, a full office productivity suite. (/usr/share/openoffice/package.env) [bsh] BeanShell: A small embeddable Java source interpreter (/usr/share/bsh/package.env) [tomcat-servlet-api-2.3] Tomcat's Servlet API 2.3/JSP API 1.2 implementation (/usr/share/tomcat-servlet-api-2.3/package.env) [hsqldb] The leading SQL relational database engine written in Java. (/usr/share/hsqldb/package.env) [libreadline-java] A JNI-wrapper to GNU Readline. (/usr/share/libreadline-java/package.env)
And more reports from java-config $ java-config -jcJtf /opt/sun-jdk-1.6.0.13/bin/jar /opt/sun-jdk-1.6.0.13/bin/javac /opt/sun-jdk-1.6.0.13/bin/java /opt/sun-jdk-1.6.0.13/lib/tools.jar sun-jdk-1.6 But nowhere there is any reference to 1.5!
(In reply to comment #5) > Could there be a connection with bug 267548 ? > > When I run > > $ java-check-environment > > it complains I have no generation-1 VM installed - which is absolutely true. > And I actually do *not* want to install one either! > > According to 'equery depend', none of my installed ebuilds need jdk-1.4 or > less, including OOO. > > But is that true? > > Perhaps OOO *does* require a generation-1 VM, and the dependency information in > the ebuild is incomplete? It does not require gen-1 VM, this is not the cause. (In reply to comment #6) > Some other thing that worries me is the > > JAVACFLAGS="-source 1.5 -target 1.5" > > diagnostic message: I do not have jdk-1.5 installed at all - just jdk-1.6! > > Where does that "1.5" come from? This just means the bytecode that it builds is compatible with 1.5, not that you need to have 1.5 jdk. Again, not connected to the problem. But in the end you were right about java, your problem is this: Error occurred during initialization of VM Could not reserve enough space for object heap Could not create the Java virtual machine. How much memory and swap does the machine have?
(In reply to comment #9) > This just means the bytecode that it builds is compatible with 1.5, not that > you need to have 1.5 jdk. Again, not connected to the problem. Thank you for explaining. > Could not reserve enough space for object heap > Could not create the Java virtual machine. Aaaarrrrrggghhh! MEMORY OVERCOMMIT! AGAIINNN!!! Yes, I should know. It has happened before. And I bet it will happen again! ;-) ...but I never seem to learn! This is not the first time I had troubles with weird JVM memory allocations - only the first time it happened when building OOO. (The other memory-waster has been the building of dev-util/netbeans.) > How much memory and swap does the machine have? Well, 8 GB RAM plus 5 GB swap file. BUT. Memory Overcommit has been disabled! The reason is that I run PostgreSQL, and the PostgreSQL-FAQ strongly recommends disabling memory overcommitting on boxes running database servers, because otherwise the server might be killed when an OOM condition is detected and the kernel starts to kill likely candidates in order to get more memory. Until now, 13 GB virtual memory has been enough to build any package, including OOO 3.0.0 (I actually failed *re*-emerging it, triggered by revdep-rebuild) - but obviously this has changed. Maybe it's the JDK itself - I think at the time I built OOO 3.0 the first time, I was still using JDK-1.5. Seems the 1.6 JRE now uses *insane* amounts of pre-allocated memory, and therefore 13 GB are not longer enough! Also, that insane amount of allocated memory is obviously never actually used, because otherwise the default (memory overcommitting is enabled) would not help: Memory overcommitting is just a way of the OS lying to the applications, telling them there were more virtual memory available than there actually is. So it lets them allocate insane amount of virtual memory without returning an error, even if that "committed" memory is only partially backed up by available RAM or swap file. As the kernel's overcommit ratio is 50 % by default, I should be able to compile OOO once I increase the swap file by another 7 GB, i. e. 12 GB swap in total. Or I re-enable memory overcommitting temporarily for the duration of the ebuild. (However, that's a bit risky to do on a server machine, as the kernel might kill important and totally unrelated services whenever a *real* memory shortage should happen during the build.) But I note that this problem must be somehow 64-bit specific: I was able to recompile OOO successfully on a different server machine a couple of days ago, and that machine had only 500 MB RAM and 2 GB swap! (Using the same GCC and JDK versions.) However, it was just a 32 bit box, and therefore different hardcoded limits for the JAVA VM might apply. So, while your comment has undoubtedly explained the primary cause of the problem and what to do about it, and therefore resolved the original issue, a new issue arises: Why are 13 GB virtual memory not enough to build OOO on amd64, where 2.5 GB virtual memory have been enough to build OOO on x86? (And memory overcommit was disabled there also for the same reasons.) I could understand if a 64 bit machine required approximately twice the amount of memory for doing the same thing as a 32 bit machine - but 2.5 GB vs. more than 13 GB memory requirements seems to a bit unbalanced to me... As far as I recall, the java VM allows the amount of allocated memory to be specified as a command line argument. Perhaps the ebuild could use this feature to restrict the amount of memory to a reasonable value?
Regarding the insane amount of virtual memory required by the JVM in the OOO build, a different suspicion occurred to me: The machine where the build failed has been a quadcore-machine, where the machine which ran the build successfully has been a single-core machine. And by default I run my quadcore-machine with MAKEOPTS="-j5". Therefore, it this applies to the OOO JVM usage also, it might be that 5 JVM processes are started, each one requiring not more than 2.5 GB virtual memory, yet this gives 12.5 GB in total! And assuming that 64 bit JVM requires more memory by a certain factor than a 32 bit JVM does, that would totally explain why 13 GB virtual memory are not enough on amd64! It this suspicion should actually turn out to be right, then the ebuild should restrict the -j option of MAKEFLAGS to a lower value (such as -j1), at least as far as JVM invocations are concerned. Just imagine what will happen it the new announced sixcore-machines actually hit the market and people start using MAKEFLAGS="-j7"... ;-)
Is this still an issue with 3.1.1? Besides that I'm quite clueless what we as a distro do here, guess this would be best to report upstream at http://qa.openoffice.org/issue_handling/pre_submission.html
(In reply to comment #12) > Is this still an issue with 3.1.1? It builds now fine for me. But then I have also removed the "nsplugin" USE flag. Perhaps this fact alone was enough to make it work. So the question remains whether 3.1.1 still builds with "nsplugin" enabled. I suggest we close this bug with resolution TEST-REQUEST in case someone wants to test building 3.1.1 with +nsplugin.
No need for a test request, there are lots of people building OOo with nsplugin (me included), so closing this one. Thanks for reporting back.
