When emerging openoffice 2.0.3, the compile phase completes, but the emerge fails during install. When it does, I still have 1.6GB available on my hard disk. The error : services.rdb can be created Languages: en-US ######################################################## ... checking required files ... ...... searching zip ... Found: /usr/bin/zip ...... searching unzip ... Found: /usr/bin/unzip ... analyzing openoffice.lst ... ... analyzing script: /var/tmp/portage/openoffice-2.0.3/work/ooo-build-ooc680-m7/build/ooc680-m7/solver/680/unxlngi6.pro/bin/setup_osl.ins ... ... analyzing directories ... ... analyzing files ... ... analyzing scpactions ... ... analyzing shortcuts ... ... analyzing profile ... ... analyzing profileitems ... ... analyzing modules ... ------------------------------------ ... languages en-US ... ... analyzing files ... ... analyzing files with flag ARCHIVE ... ... analyzing files with flag SCPZIP_REPLACE ... ... analyzing files with flag PATCH_SO_NAME ... ... creating preregistered services.rdb ... ... cleaning the output tree ... ... removing directory /var/tmp/portage/openoffice-2.0.3/work/ooo-build-ooc680-m7/build/ooc680-m7/instsetoo_native/util/OpenOffice//zip/en-US ... ... removing directory /var/tmp/portage/openoffice-2.0.3/work/ooo-build-ooc680-m7/build/ooc680-m7/instsetoo_native/util/OpenOffice//services.rdb/en-US_witherror_1 ... ************************************************** ERROR: ERROR: Could not register all components! in function: create_services_rdb ************************************************** My emerge info : Portage 2.1.1_pre2-r2 (default-linux/x86/2006.0, gcc-4.1.1/vanilla, glibc-2.4-r3, 2.6.17-gentoo i686) ================================================================= System uname: 2.6.17-gentoo i686 Mobile Intel(R) Pentium(R) 4 - M CPU 2.00GHz Gentoo Base System version 1.12.1 dev-lang/python: 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.18.1 sys-devel/autoconf: 2.13, 2.60 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.17 sys-devel/gcc-config: [Not Present] sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -pipe -O2 -fomit-frame-pointer -ffast-math" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/eselect/compiler /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=pentium4 -pipe -O2 -fomit-frame-pointer -ffast-math -fvisibility-inlines-hidden" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--as-needed" 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/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X aac acpi alsa aotuv apache2 avi bash-completion berkdb bitmap-fonts bzip2 cairo cdparanoia cdr cjk cli crypt cups dbus dlloader dri dts dv dvd dvdread dynagraph edl effects emboss emf encode firefox flac fontconfig foomaticdb fortran fpx gdbm gif glibc-omitfp glitz gmail gnome gphoto2 graphviz gs gtk gtk2 hal howl i8x0 imap imlib inkjar ipv6 isdnlog java jbig jpeg jpeg2k lcms libg++ libwww live logrotate lzo mad matroska mikmod mmx mmxext motif moznocompose moznoirc moznomail mozsvg mp3 mpeg nautilus ncurses nls nptl nptlonly nsplugin ogg opengl oss pam pcre pdf pdflib perl pic plotutils plugin png ppds pppd python quicktime radeon readline reflection rle rtc samba sdl session silc speex spell spl sse sse2 ssl svg tcltk tcpd theora tiff truetype truetype-fonts type1-fonts udev unicode userlocales vorbis win32codecs wmf xanim xml xml2 xorg xpm xv xvid xvmc zlib elibc_glibc input_devices_keyboard input_devices_mouse kernel_linux userland_GNU video_cards_radeon" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS Please find below the install log generated by openoffice.
Created attachment 91039 [details] log_OOC680__en-US.log The log file, as generated by the openoffice installation scripts.
The following line seems to be the culprit. I've had the same issue, I'm going to try emerging OO without the python USE flag and see if that works for now. /var/tmp/portage/openoffice-2.0.3/work/ooo-build-ooc680-m7/build/ooc680-m7/solver/680/unxlngi6.pro/bin/regcomp -register -br /var/tmp/portage/openoffice-2.0.3/work/ooo-build-ooc680-m7/build/ooc680-m7/solver/680/unxlngi6.pro/bin/types.rdb -br /var/tmp/portage/openoffice-2.0.3/work/ooo-build-ooc680-m7/build/ooc680-m7/solver/680/unxlngi6.pro/bin/pyuno_services.rdb -r /var/tmp/portage/openoffice-2.0.3/work/ooo-build-ooc680-m7/build/ooc680-m7/instsetoo_native/util/OpenOffice//services.rdb/en-US_inprogress_1/services.rdb -c vnd.openoffice.pymodule:mailmerge -l com.sun.star.loader.Python 2>&1 |
Looks like bug 126777. python compiled with CFLAGS -ffast-math. Any chance the python ebuild filters that flag?
Reassigning. python-herd, please see Hannos last comment and the link to the other bug. Would it be possible for you to filter --fast-math on the python-ebuild, it breaks our build...
I'd prefer to die on any CFLAGS setting that specifies -ffast-math. It is an unsafe flag that is clearly documented as such. If people still want to use it, we should no go through lengths to allow them to maintain their illusions that fast-math can be used globally.
(In reply to comment #5) > I'd prefer to die on any CFLAGS setting that specifies -ffast-math. It is an > unsafe flag that is clearly documented as such. If people still want to use it, > we should no go through lengths to allow them to maintain their illusions that > fast-math can be used globally. > You mean globally or in openoffice? Cause if we do the latter, I guess people will most likely just remove --ffast-math from the their CFLAGS, try again and fail with this, again...
IMHO flags like -ffast-math which are documented as changing the behaviour of the compiled code (not just "optimizing" it to go faster) should not be supported in system-wide CFLAGS. See also bug 126777 comment 25. As far as I can tell from the gcc man page it is more than just possibly "inaccurate" math: things involving NaN and Inf are no longer supported at all. So this should only be enabled by the build system for a package that knows it does not need this, not in system-wide flags.
This whole issue doesn't seem to be only "--fast-math" related. It also occurs on the ppc platform with the following CFLAGS: "-O2 -mcpu=G4 -mtune=G4 -maltivec -mabi=altivec -fno-strict-aliasing -pipe"
Christian, that is probably a bug. -ffast-math is a severe case of pebkac. Andreas, I think that openoffice and python should both die on -ffast-math. The openoffice die should also refer to ffast-math in python.
(In reply to comment #9) > Andreas, I think that openoffice and python should both die on -ffast-math. The > openoffice die should also refer to ffast-math in python. Paul, why not filtering --fast-math in python, instead of dying, since openoffice already filters it ? Denis.
Denis, quite simple. -ffast-math is broken and short-sighted for a global flag. Filtering gives the shortsighted message that it works globally, while it is not suited for any package not specifically tested for it. As it breaks python, dieing makes people understand that it does not work on python. It is better than the alternative of not looking for it at all.
(In reply to comment #9) > Christian, that is probably a bug. -ffast-math is a severe case of pebkac. > Andreas, I think that openoffice and python should both die on -ffast-math. The > openoffice die should also refer to ffast-math in python. > Thats what I think as well. See my post in the forum: http://forums.gentoo.org/viewtopic-t-478378.html This issue should be fixed ASAP, since it's really unsatisfying. I'm trying to do my best to help resolve the issue but I'm not a programmer.
The problem was caused by hunspell-1.14 (at least on PPC arch). After updating to 1.1.4-r1, the problem was gone.
(In reply to comment #13) > The problem was caused by hunspell-1.14 (at least on PPC arch). After updating > to 1.1.4-r1, the problem was gone. > That's another bug
So what do you want the python folks to do now? Add a "die" for each and every unsupported CFLAG that might break it? imho this is just weird, people using unsupported flags should stop using them, I don't think it makes much sense to maintain a list of globally unsupported flags in the python ebuild.
I'm still not sure, what to do here, I mean I surely can make openoffice die if --ffast-math is used, but actually I think it would be better to come to a more global solution than that...
(In reply to comment #16) > I'm still not sure, what to do here, I mean I surely can make openoffice die if > --ffast-math is used, but actually I think it would be better to come to a more > global solution than that... I tried to trigger some discussion about this on gentoo-dev@ [1] but it didn"t generate much interest. Maybe you could consider contributing to the thread ? Denis. [1] http://thread.gmane.org/gmane.linux.gentoo.devel/40362/focus=40362
If --fast-math exposes bugs in Python, then a test should be submitted upstream as part of their make check that will fail if --fast-math is used. If no such test exists, then there is a differnt issue that --fast-math being used. As is, Python's test suite all passes with -ffast-math for me. That is the better solution. It would demonstrate that Python did not build properly whether or not the system were Gentoo. If that were done, the Python configure script could also add a flag to turn off the specific optimization enabled by -ffast-math that breaks it.
I would agree with adding such a test to the python test suite. I don't see though a need for upstream python to remove things in the configure script. It is up to them though.
I had a similar install failure here, but with python build with realy standard CFLAGS (CFLAGS="-mcpu=G4 -mtune=G4 -O2 -fomit-frame-pointer -maltivec -mabi=altivec -pipe")
Created attachment 94184 [details] emerge --info
Created attachment 94187 [details] Failed install log
Illusion. Your bug does not seem to be entirely equal to this one. I did however check out on the ppc flags. You don't need to specify -maltivec as it is selected automatically by the -mcpu flag. The -mabi flag however does seem to be a bit dangerous and could very well cause your problems.
CFLAGS are taken from "Safe CFLAGS" article from Wiki and as far I know they are common for G4. I can try without mabi, but this is hard a bit because OO build takes ~18h onthis machine :/ This is real shame that there is no openoffice-bin for PPC, I realy hate to build this package because it likes to fail on install after many hours of compilation ... grrr
Also what is helpfull is a compilation log (the complete output of portage). That is often more insightfull than an openoffice installation log.
(In reply to comment #23) > Illusion. Your bug does not seem to be entirely equal to this one. I did > however check out on the ppc flags. You don't need to specify -maltivec as it > is selected automatically by the -mcpu flag. The -mabi flag however does seem > to be a bit dangerous and could very well cause your problems. It does not matter if any AltiVec-Options are set. During 2006.1-building I found out, that OOo could be built with the ppc-generic-profile only. As soon as I use a G3 or G4 subprofile it fails. Filtering out -mtune={G3,G4} and -mcpu={G3,G4} in the OOo-ebuild does not help. It seems that the problem lays deeper with a dependency that is compiled with optimized ppc-CFLAGS.
OOo problem on ppc seems to be caused by compiler bug IMHO I was able to build OOo for G4 fine using specyfic CFLAGS. Take a look at http://bugs.gentoo.org/show_bug.cgi?id=143882 Generaly only mcpu=7400 works here. Anything else cause OOo to fail on install when registering python UNO modules.
*** Bug 146861 has been marked as a duplicate of this bug. ***
As no other solution seems to pop up anywhere, I've now added a line to the openoffice-ebuild to break when -ffast-math is in the CFLAGS. Original problem is solved by this, so closing
