Bugzilla Bug 139412

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 an attachment (id=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 an attachment (id=94184) [details]
emerge --info

Created an attachment (id=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