build of openoffice fails: ------------------------------ Making Module-Definitionfile : ../unxlngi6.pro/misc/uno_sal.def just a dummy for UNIX ------------------------------ Making Module-Definitionfile : ../unxlngi6.pro/misc/sal_textenc.def just a dummy for UNIX cp -f /data/porttmp/portage/app-office/openoffice-2.1.0-r1/work/ooo/build/OOE680_m6/solenv/src/default_description.xml ../unxlngi6.pro/misc/uno_sal.xml xml2cmp -func ../unxlngi6.pro/misc/uno_sal_description.cxx ../unxlngi6.pro/misc/uno_sal.xml dmake: Error code 139, while making '../unxlngi6.pro/misc/uno_sal_description.cxx' '---* tg_merge.mk *---' ERROR: Error 65280 occurred while making /data/porttmp/portage/app-office/openoffice-2.1.0-r1/work/ooo/build/OOE680_m6/sal/util make: *** [stamp/build] Fehler 1 !!! ERROR: app-office/openoffice-2.1.0-r1 failed. Call stack: ebuild.sh, line 1614: Called dyn_compile ebuild.sh, line 971: Called qa_call 'src_compile' environment, line 5406: Called src_compile openoffice-2.1.0-r1.ebuild, line 326: Called die !!! 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/portage/app-office:openoffice-2.1.0-r1:20070331-091805.log'. !!! When you file a bug report, please include the following information: GENTOO_VM=sun-jdk-1.5 CLASSPATH="" JAVA_HOME="/opt/sun-jdk-1.5.0.10" JAVACFLAGS="-source 1.4 -target 1.4" COMPILER="" and of course, the output of emerge --info [ebuild U ] app-office/openoffice-2.1.0-r1 [2.0.4] USE="cups firefox java kde ldap pam -binfilter -branding -cairo -dbus -debug -eds -gnome -gstreamer -gtk -odk -seamonkey% -sound -webdav" LINGUAS="de en_GB it -af -ar -as_IN% -be_BY -bg -bn -bs -ca -cs -cy -da -el -en -en_US -en_ZA -es -et -fa -fi -fr -gu_IN -he -hi_IN -hr -hu -ja -km -ko -lt -lv -mk -nb -nl -nn -nr -ns -or_IN% -pa_IN -pl -pt -pt_BR -ru -rw -sh_YU -sk -sl -sr_CS -st -sv -sw_TZ -ta_IN% -te_IN% -tg% -th -ti_ER% -tn -tr -ts -ur_IN% -ve% -vi -xh -zh_CN -zh_TW -zu" 0 kB Reproducible: Always Portage 2.1.2.2 (default-linux/x86/2006.1, gcc-4.1.1, glibc-2.5-r0, 2.6.19-gentoo-r5 i686) ================================================================= System uname: 2.6.19-gentoo-r5 i686 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ Gentoo Base System release 1.12.9 Timestamp of tree: Sat, 31 Mar 2007 08:00:01 +0000 dev-java/java-config: 1.3.7, 2.0.31 dev-lang/python: 2.3.5-r3, 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=athlon64 -pipe -msse3 -fomit-frame-pointer" CHOST="i686-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 /var/qmail/alias /var/qmail/control" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/php/apache1-php4/ext-active/ /etc/php/apache1-php5/ext-active/ /etc/php/apache2-php4/ext-active/ /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php4/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php4/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -march=athlon64 -pipe -msse3 -fomit-frame-pointer" 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" LANG="de_DE@euro" LC_ALL="de_DE@euro" LINGUAS="de en_GB it" 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 --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/data/porttmp/" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://cb1.cb.home/gentoo-portage" USE="3dnow 3dnowext X alsa arts berkdb bitmap-fonts cdb cdparanoia cdr cli cracklib crypt cups divx4linux dri dvd dvdread encode fam fortran ftp gd gdbm gif gpm iconv ipv6 isdnlog java jpeg kde ldap libg++ maildir midi mmx mmxext mp3 mpeg mysql ncurses nls nptl nptlonly nvidia opengl pam pcre perl php png ppds pppd python qt readline recode reflection session spl sse sse2 ssl tcpd truetype-fonts type1-fonts unicode usb x86 xorg zlib" ALSA_CARDS="snd-intel8x0" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de en_GB it" USERLAND="GNU" VIDEO_CARDS="nvidia nv vesa fbdev" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
complete build log: http://www.cb-world.de/app-office:openoffice-2.1.0-r1:20070331-091805.log
*** Bug 172862 has been marked as a duplicate of this bug. ***
xml2cmp segfaults, which means that STLport is not built with large file support. @dev-zero Please move 'append-lfs-flags' to head of src_compile function in STLport ebuild and change it to 'append-flags -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE', thanks. Why? Because 'append-lfs-flags' adds them to cppflags only, which is neither CFLAGS nor CXXFLAGS. So it is not used.
[...] > ERROR: Error 65280 occurred while making > /data/porttmp/portage/app-office/openoffice-2.1.0-r1/work/ooo/build/OOE680_m6/sal/util > make: *** [stamp/build] Fehler 1 > > !!! ERROR: app-office/openoffice-2.1.0-r1 failed. [...] exactly the same for me with app-office/openoffice-2.1.0-r1 [2.0.4] USE="cairo cups dbus eds firefox gnome gstreamer gtk java ldap pam sound -binfilter -branding -debug -kde -odk -seamonkey% -webdav" LINGUAS="de en -af -ar -as_IN% -be_BY -bg -bn -bs -ca -cs -cy -da -el -en_GB -en_US -en_ZA -es -et -fa -fi -fr -gu_IN -he -hi_IN -hr -hu -it -ja -km -ko -lt -lv -mk -nb -nl -nn -nr -ns -or_IN% -pa_IN -pl -pt -pt_BR -ru -rw -sh_YU -sk -sl -sr_CS -st -sv -sw_TZ -ta_IN% -te_IN% -tg% -th -ti_ER% -tn -tr -ts -ur_IN% -ve% -vi -xh -zh_CN -zh_TW -zu" on Portage 2.1.2.2 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.5-r0, 2.6.19-gentoo-r5 i686) ================================================================= System uname: 2.6.19-gentoo-r5 i686 AMD Athlon(tm) XP 2400+ Gentoo Base System release 1.12.9 Timestamp of tree: Sat, 31 Mar 2007 09:50:01 +0000 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-java/java-config: 1.3.7, 2.0.31 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-ggdb" CHOST="i686-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/terminfo /etc/texmf/web2c" CXXFLAGS="-ggdb" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig collision-protect distlocks metadata-transfer sandbox sfperms splitdebug strict" GENTOO_MIRRORS="http://gentoo.ynet.sk/pub " LANG="en_US.utf8" LC_ALL="en_US.utf8" LINGUAS="en de" MAKEOPTS="-j2" 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 --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://192.168.0.1/gentoo-portage" USE="3dnow 3dnowext X a52 aac acpi aiglx alsa audiofile avahi beagle berkdb bitmap-fonts bzip2 cairo cdr cli cracklib crypt css cups dbus dlloader dri dvd dvdr dvdread eds emboss encode evo exif fam fbcon ffmpeg firefox flac fortran gdbm gif ginac gmp gnome gnutls gphoto2 gpm gstreamer gtk gtk2 hal iconv icq ipod ipv6 isdnlog java javascript jpeg jpeg2k lcms ldap libg++ mad midi mikmod mime mmx mmxext mono mozsvg mp3 mpeg msn nautilus ncurses nfs nls nptl nptlonly nsplugin nvidia offensive ogg oggvorbis opengl pam pcre pdf perl plotutils png posix ppds pppd python qt3 qt4 quicktime readline real reflection ruby sdl session sockets spell spl sqlite3 sse ssl subtitles svg tcpd tetex theora threads tiff truetype truetype-fonts type1-fonts unicode usb vcd vorbis win32codecs wma x86 xattr xine xml xorg xv xvid zlib" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LINGUAS="en de" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
same for me : ------------------------------ Making Module-Definitionfile : ../unxlngi6.pro/misc/uno_sal.def just a dummy for UNIX ------------------------------ Making Module-Definitionfile : ../unxlngi6.pro/misc/sal_textenc.def just a dummy for UNIX cp -f /var/tmp/portage/app-office/openoffice-2.1.0-r1/work/ooo/build/OOE680_m6/solenv/src/default_description.xml ../unxlngi6.pro/misc/uno_sal.xml xml2cmp -func ../unxlngi6.pro/misc/uno_sal_description.cxx ../unxlngi6.pro/misc/uno_sal.xml dmake: Error code 139, while making '../unxlngi6.pro/misc/uno_sal_description.cxx' '---* tg_merge.mk *---' ERROR: Error 65280 occurred while making /var/tmp/portage/app-office/openoffice-2.1.0-r1/work/ooo/build/OOE680_m6/sal/util make: *** [stamp/build] Erreur 1 !!! ERROR: app-office/openoffice-2.1.0-r1 failed. Call stack: ebuild.sh, line 1614: Called dyn_compile ebuild.sh, line 971: Called qa_call 'src_compile' environment, line 5406: Called src_compile openoffice-2.1.0-r1.ebuild, line 326: Called die !!! 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/tmp/portage/app-office/openoffice-2.1.0-r1/temp/build.log'. !!! When you file a bug report, please include the following information: GENTOO_VM=sun-jdk-1.5 CLASSPATH="" JAVA_HOME="/opt/sun-jdk-1.5.0.10" JAVACFLAGS="-source 1.4 -target 1.4" COMPILER="" and of course, the output of emerge --info http://www.lost-online.info/~jujubickoille/infos%20gentoo%20juju.txt
I have this one as well. Java environment: GENTOO_VM=sun-jdk-1.5 CLASSPATH="" JAVA_HOME="/opt/sun-jdk-1.5.0.10" JAVACFLAGS="-source 1.4 -target 1.4" COMPILER="" and of course, the output of emerge --info My emerge --info: Portage 2.1.2.2 (default-linux/x86/2006.1, gcc-4.1.1, glibc-2.5-r0, 2.6.19-gentoo-r5 i686) ================================================================= System uname: 2.6.19-gentoo-r5 i686 AMD Sempron(tm) 2200+ Gentoo Base System release 1.12.9 Timestamp of tree: Sat, 31 Mar 2007 13:50:01 +0000 dev-java/java-config: 1.3.7, 2.0.31 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=athlon-xp -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/php/apache1-php4/ext-active/ /etc/php/apache1-php5/ext-active/ /etc/php/apache2-php4/ext-active/ /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php4/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php4/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O2 -march=athlon-xp -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.gentoo.mesh-solutions.com/gentoo/ http://mirror.uni-c.dk/pub/gentoo/ http://mirror.gentoo.no/ " LANG="da_DK.UTF8" LC_ALL="da_DK.UTF8" LINGUAS="da en" MAKEOPTS="-j2" 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 --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="/kde 3dnow X a52 aac acl acpi aim alsa apache2 audiofile bash-completion bcmath berkdb bitmap-fonts bonobo bzip2 cairo calendar caps cddb cdinstall cdparanoia cdr cli cracklib crypt cups curl curlwrappers dbus dedicated directfb doc dts dv dvb dvd dvdr dvdread eds encode esd examples exif expat fam ffmpeg firefox flac flash fltk foomaticdb fortran ftp gcj gd gdbm ggi gif glut gmp gnome gnustep gnutls gphoto2 gpm graphviz gstreamer gtk gtk2 gtkhtml guile hal iconv icq imagemagick imlib ipv6 isdnlog jabber jack java javascript jbig jikes jpeg jpeg2k junit lash lcms ldap lesstif libg++ libnotify libsamplerate libwww lm_sensors lua m17n-lib mad matroska mhash midi mikmod mime ming mmx mng mono motif mozilla mp3 mpeg msn musepack mysql mysqli nas ncurses nls nptl nptlonly nsplugin odbc offensive ogg openal opengl osc oscar oss pam pcre pdf perl php png portaudio posix postgres ppds pppd profile python qdbm qt3 qt4 quicktime rdesktop readline recode reflection ruby samba sasl scanner sdl session shorten simplexml slang sndfile soap sockets sox speex spell spl sqlite sqlite3 sse ssl startup-notification svg svga symlink szip tcl tcltk tcpd tetex theora threads tidy tiff tk tokenizer truetype truetype-fonts type1-fonts unicode usb v4l vcd videos vorbis win32codecs wmf wxwindows x264 x86 xface xml xmlrpc xorg xosd xpm xprint xsl xv xvid yahoo zlib" ALSA_CARDS="ens1371" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="da en" USERLAND="GNU" VIDEO_CARDS="nv nvidia vesa" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
My situation is almost similar (Error 65280) with some minor differences (Error code 127 - instead of 139) *** xml2cmp -func ../unxlngi6.pro/misc/uno_sal_description.cxx ../unxlngi6.pro/misc/uno_sal.xml xml2cmp: symbol lookup error: xml2cmp: undefined symbol: _ZN8stlp_std13_Filebuf_base7_M_seekExi dmake: Error code 127, while making '../unxlngi6.pro/misc/uno_sal_description.cxx' '---* tg_merge.mk *---' ERROR: Error 65280 occurred while making /var/tmp/portage/app-office/openoffice-2.1.0-r1/work/ooo/build/OOE680_m6/sal/util make: *** [stamp/build] Error 1 !!! ERROR: app-office/openoffice-2.1.0-r1 failed. Call stack: ebuild.sh, line 1614: Called dyn_compile ebuild.sh, line 971: Called qa_call 'src_compile' environment, line 5393: Called src_compile openoffice-2.1.0-r1.ebuild, line 326: Called die *** Sidenote: the good old typesconfig errors still show up: *** Mar 31 14:01:56 kernel grsec: (admin:S:/) signal 11 sent to /var/tmp/portage/app-office/openoffice-2.1.0-r1/work/ooo/build/OOE680_m6/sal/unxlngi6.pro/bin/typesconfig[typesconfig:781] uid/euid:0/0 gid/egid:0/0, parent /var/tmp/portage/app-office/openoffice-2.1.0-r1/work/ooo/build/OOE680_m6/sal/unxlngi6.pro/bin/typesconfig[typesconfig:776] uid/euid:0/0 gid/egid:0/0 Mar 31 14:01:56 szk-simor kernel: (admin:S:/) denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /var/tmp/portage/app-office/openoffice-2.1.0-r1/work/ooo/build/OOE680_m6/sal/unxlngi6.pro/bin/typesconfig[typesconfig:781] uid/euid:0/0 gid/egid:0/0, parent /var/tmp/portage/app-office/openoffice-2.1.0-r1/work/ooo/build/OOE680_m6/sal/unxlngi6.pro/bin/typesconfig[typesconfig:776] uid/euid:0/0 gid/egid:0/0 ***
(In reply to comment #7) Exactly the same symptoms at #172925 Regards, Dw.
*** Bug 172925 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > xml2cmp segfaults, which means that STLport is not built with large file > support. > > @dev-zero > Please move 'append-lfs-flags' to head of src_compile function in STLport > ebuild and change it to 'append-flags -D_FILE_OFFSET_BITS=64 > -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE', thanks. > > Why? Because 'append-lfs-flags' adds them to cppflags only, which is neither > CFLAGS nor CXXFLAGS. So it is not used. > This fixed it for me! Thanks
Created attachment 115116 [details, diff] Does what comment #3 says Perhaps a patch will spur the quick fixing of this issue? This is hitting an awful lot of people and I'm really tired of all the "Gentoo sucks" threads on the forums.
*** Bug 172951 has been marked as a duplicate of this bug. ***
Please fix this ASAP. This has hit quite a few people, judging by the number of posts in forums and duplicate bugs. If the problem is the STLport ebuild, update the ebuild. A bug like this reflects bad on Gentoo.
Reassigning to cpp-herd, has to be fixed in STLport
(In reply to comment #3) > Please move 'append-lfs-flags' to head of src_compile function in STLport > ebuild and change it to 'append-flags -D_FILE_OFFSET_BITS=64 > -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE', thanks. This has fixed it for me too. So go ahaed with this, IMHO. Regards, Attila
@Hanno: [...] Don't forget to define _STLP_USE_BOOST_SUPPORT in stlport/stl/config/user_config.h file make: Entering directory `/var/tmp/portage/dev-libs/STLport-5.1.2/work/STLport-5.1.2/build/lib' i686-pc-linux-gnu-g++ -pthread -fexceptions -fident -fPIC -fuse-cxa-atexit -march=pentium4 -O3 -pipe -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_REENTRANT -D_STLP_REAL_LOCALE_IMPLEMENTED -D_GNU_SOURCE -I../../stlport -I/usr/include -c -o obj/gcc/so/dll_main.o ../../src/dll_main.cpp i686-pc-linux-gnu-g++ -pthread -fexceptions -fident -fPIC -fuse-cxa-atexit -march=pentium4 -O3 -pipe -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_REENTRANT -D_STLP_REAL_LOCALE_IMPLEMENTED -D_GNU_SOURCE -I../../stlport -I/usr/include -c -o obj/gcc/so/fstream.o ../../src/fstream.cpp i686-pc-linux-gnu-g++ -pthread -fexceptions -fident -fPIC -fuse-cxa-atexit -march=pentium4 -O3 -pipe -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_REENTRANT -D_STLP_REAL_LOCALE_IMPLEMENTED -D_GNU_SOURCE -I../../stlport -I/usr/include -c -o obj/gcc/so/strstream.o ../../src/strstream.cpp i686-pc-linux-gnu-g++ -pthread -fexceptions -fident -fPIC -fuse-cxa-atexit -march=pentium4 -O3 -pipe -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_REENTRANT -D_STLP_REAL_LOCALE_IMPLEMENTED -D_GNU_SOURCE -I../../stlport -I/usr/include -c -o obj/gcc/so/sstream.o ../../src/sstream.cpp i686-pc-linux-gnu-g++ -pthread -fexceptions -fident -fPIC -fuse-cxa-atexit -march=pentium4 -O3 -pipe -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_REENTRANT -D_STLP_REAL_LOCALE_IMPLEMENTED -D_GNU_SOURCE -I../../stlport -I/usr/include -c -o obj/gcc/so/ios.o ../../src/ios.cpp i686-pc-linux-gnu-g++ -pthread -fexceptions -fident -fPIC -fuse-cxa-atexit -march=pentium4 -O3 -pipe -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_REENTRANT -D_STLP_REAL_LOCALE_IMPLEMENTED -D_GNU_SOURCE -I../../stlport -I/usr/include -c -o obj/gcc/so/stdio_streambuf.o ../../src/stdio_streambuf.cpp [...] It seems that append-lfs-flags is not ignored. Could you please send me (via email maybe) the log of the STLport build? Thanks.
No need for logs. My change helped others. I wonder where STLport-5.1.2 comes from, not from portage. There, I only see 5.1.0. http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-libs/STLport/ And others help my change. May be you have an updated version in overlay that works again?
first. But as far as I can tell, nothing has changed in respect to the lfs-support. This is from STLport-5.1.0: [...] >>> Source unpacked. >>> Compiling source in /var/tmp/portage/dev-libs/STLport-5.1.0/work/STLport-5.1.0 ... Don't forget to define _STLP_USE_BOOST_SUPPORT in stlport/stl/config/user_config.h file make: Entering directory `/var/tmp/portage/dev-libs/STLport-5.1.0/work/STLport-5.1.0/build/lib' i686-pc-linux-gnu-g++ -pthread -fexceptions -fident -fPIC -fuse-cxa-atexit -march=pentium4 -O3 -pipe -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_REENTRANT -D_STLP_REAL_LOCALE_IMPLEMENTED -D_GNU_SOURCE -I../../stlport -I/usr/include -c -o obj/gcc/so/dll_main.o ../../src/dll_main.cpp i686-pc-linux-gnu-g++ -pthread -fexceptions -fident -fPIC -fuse-cxa-atexit -march=pentium4 -O3 -pipe -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_REENTRANT -D_STLP_REAL_LOCALE_IMPLEMENTED -D_GNU_SOURCE -I../../stlport -I/usr/include -c -o obj/gcc/so/fstream.o ../../src/fstream.cpp i686-pc-linux-gnu-g++ -pthread -fexceptions -fident -fPIC -fuse-cxa-atexit -march=pentium4 -O3 -pipe -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_REENTRANT -D_STLP_REAL_LOCALE_IMPLEMENTED -D_GNU_SOURCE -I../../stlport -I/usr/include -c -o obj/gcc/so/strstream.o ../../src/strstream.cpp Interrupted. [...] ... which shows that also in STLport-5.1.0 append-lfs-flags seems to work. And I need to know why append-lfs-flags works here (and obviously for some other devs since they tested it) and for some people it doesn't. So please, please attach your build log.
Created attachment 115169 [details] Emerge log of dev-libs/STLport-5.1.0 I re-emerged STLport and collected the attached log of the output. I tried enabling the 'boost' use flag -- that didn't help either. If you need any further information, please let me know.
A diff between the build log for the STLport-5.1.0 in portage and the STLport-5.1.0 with the patch from comment #3 shows no difference except the original is missing "-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE" in all the compile operations. The patched version has them after the users own CXXFLAGS but before " -D_REENTRANT etc.etc." from /usr/portage/eclass/flag-o-matic.eclass: append-cppflags() { [[ -z $* ]] && return 0 export CPPFLAGS="${CPPFLAGS} $*" return 0 } append-lfs-flags() { [[ -n $@ ]] && die "append-lfs-flags takes no arguments" append-cppflags -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE } from /usr/portage/dev-libs/STLport/STLport-5.10.ebuild: append-lfs-flags # It's not an autoconf script ./configure \ ${myconf} \ --with-extra-cxxflags="${CXXFLAGS}" || die "configure failed" So I see no reason why CPPFLAGS would make it in.
Created attachment 115176 [details] complete STLport and openoffice emerge logs I have exaxtly the same problem as described in comment #1. I tried with STLport using "boost" and without it. The openoffice build stops exactly at the same position, with the same error (139 and 65280). You should find all relevant logs in the attachment. Please fix this... BTW, there is STLport 5.1.2 available upstream, maybe this helps?
(In reply to comment #20) ... > export CPPFLAGS="${CPPFLAGS} $*" ... > --with-extra-cxxflags="${CXXFLAGS}" || die "configure failed" > > So I see no reason why CPPFLAGS would make it in. > One is 'CPPFLAGS', the other is 'CXXFLAGS'. I don't know of those two variables get merged together into 'CXXFLAGS' somewhere else, but if not that might be the problem.
(In reply to comment #22) > (In reply to comment #20) > ... > > export CPPFLAGS="${CPPFLAGS} $*" > ... > > --with-extra-cxxflags="${CXXFLAGS}" || die "configure failed" > > > > So I see no reason why CPPFLAGS would make it in. > > > > One is 'CPPFLAGS', the other is 'CXXFLAGS'. I don't know of those two > variables get merged together into 'CXXFLAGS' somewhere else, but if not that > might be the problem. > Yes, that was my point. But as I see it, right now we have a patient bleeding to death on the table. We have the means and need to stop the bleeding now. We can nitpick about the propper tool to use to stitch up the patient later. This is a big bug in the number of users it is hitting. Even after this is fixed, there will be many more reporting dupes over the next month wasting the users and bug wranglers' time because they don't sync up. The longer this bug remains unresolved the more dupes there will be, the more whining about Gentoo people will do and the more collective time will be wasted all around.
append-lfs-flags appears to be ignored on my system no matter where the placement
Got hit by this one too.
(In reply to comment #23) > > But as I see it, right now we have a patient bleeding to death on the table. > We have the means and need to stop the bleeding now. We can nitpick about the > propper tool to use to stitch up the patient later. > > This is a big bug in the number of users it is hitting. Even after this is > fixed, there will be many more reporting dupes over the next month wasting the > users and bug wranglers' time because they don't sync up. The longer this bug > remains unresolved the more dupes there will be, the more whining about Gentoo > people will do and the more collective time will be wasted all around. > Exactly what I think. Since this affects stable package, either a fix should be quickly committed or the ebuild should masked until the issue is solved. This is hitting more and more people by the minute.
Same bug, and patch provided works. Here is my emerge --info, for informations Portage 2.1.2.2 (default-linux/x86/2006.1, gcc-4.1.1, glibc-2.5-r0, 2.6.20 i686) ================================================================= System uname: 2.6.20 i686 Intel(R) Pentium(R) 4 CPU 2.60GHz Gentoo Base System release 1.12.9 Timestamp of tree: Sun, 01 Apr 2007 09:50:01 +0000 dev-java/java-config: 1.3.7, 2.0.31 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O3 -pipe -march=pentium4" CHOST="i686-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/terminfo" CXXFLAGS="-O3 -pipe -march=pentium4" DISTDIR="/var/spool/distfiles" FEATURES="distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://mir.zyrianes.net/gentoo/ http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/ http://www.mirrorservice.org/sites/www.ibiblio.org/gentoo/ http://mir.zyrianes.net/gentoo/" LANG="fr_FR@euro" LINGUAS="fr" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages/x86" 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 --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/mnt/space/2/" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/tmp/portage" SYNC="rsync://rsync.fr.gentoo.org/gentoo-portage" USE="X a52 aac aiglx alsa amr amuled audiofile authfile bash-completion berkdb bitmap-fonts bluetooth bzip2 cairo cdparanoia cdr chardet cli cracklib crypt curl dbus divx4linux dri dts dv dvd dvdr dvdread encode esd exif expat fame ffmpeg firefox fortran gd gdbm gif glitz glut gmp gnome gphoto2 gpm gstreamer gtk gtk2 hal httpd iconv idea idn imagemagick imap imlib irda isdnlog ithreads java jpeg jpeg2k ldap libcaca libg++ live mad matroska midi mjpeg mmx mozcalendar mozsvg mp3 mpeg msn ncurses nls nptl nptlonly nvidia ogg oggvorbis opengl openntpd pam pcre pdf perl png ppds pppd python readline reflection sdl session smp softmmu speex spl sse sse2 ssl stream subtitles svg syslog sysvipc tcltk tcpd theora threads threadsafe tiff truetype truetype-fonts type1 type1-fonts udev unicode usb v4l v4l2 vorbis win32codecs wmf wxwindows x86 xinetd xml xorg xosd xpm xv xvid zlib" ALSA_CARDS="intel8x0" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="fr" USERLAND="GNU" VIDEO_CARDS="nv" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
(In reply to comment #11) > Created an attachment (id=115116) [edit] > Does what comment #3 says > > Perhaps a patch will spur the quick fixing of this issue? This is hitting an > awful lot of people and I'm really tired of all the "Gentoo sucks" threads on > the forums. > Applying the patch from Gordon Malm works for me.
ok, there have been two problems: a) My local account does something weird: instead of setting CPPFLAGS to "-D_...", it adds the contents of it to CFLAGS and then to CXXFLAGS. This was the reason why the "-D_..." have always been added on my machine. b) STLport overrides the CPPFLAGS defined in the environment (see build/Makefiles/gmake/gcc.mak). Extending the sed-line to replace CPPFLAGS in the Makefile is the real solution and NOT adding the lfs-flags to CFLAGS and CXXFLAGS. ... and please: If you don't have anything substantial to write, just don't write it. I'm working hard and I'm working a lot and I don't get paid for it. And committing a fix without knowing what the real problem was is bad and will in 99% percent of the cases break things in the future. So, if you think you can do better than me, why not become a dev yourself? You can join #gentoo-cpp on irc.freenode.net for example and talk to me about it. Writing an email is also a good idea. @Andy Dalton: Thanks for the help. I really appreciated it.
This one is *still not* fixed, although there is a solution mentioned in https://bugs.gentoo.org/show_bug.cgi?id=146242 Could somebody *please apply the provided patch for STLport an commit it to portage? Many thanks! Best regards Jan
@Jan: did you try version 5.1.2 ?
No, just patched 5.1.0 as I'm using (mostly) stable. But I have another computer on which I'll test that and report. Best regards Jan
Just resynced and tested: Both the patch and version 5.1.2 work like a charm for me. So I'd suggest to mark STLpot-5.1.2 stable as openoffice.org-2.1.0-r1 already is declared stable? Best regards Jan
If I understand correctly, we still have a situation where stable is broken, and OpenOffice, arguably one of the most critical user applications in the tree, cannot be compiled. Please either stabilize STLport-5.1.2, where the fix has been applied, OR revbump 5.1.0 with a fix. Policy is that stable ebuilds in the tree must be able to build out of the box.
(In reply to comment #34) > If I understand correctly, we still have a situation where stable is broken, > and OpenOffice, arguably one of the most critical user applications in the > tree, cannot be compiled. Yes, indeed.
*** Bug 173062 has been marked as a duplicate of this bug. ***
@Mike: I know the policies very well. One policy is: Reset keywords to unstable on rev.bumps. Another policy is: A package has to be in the tree for 30 days without problems until it can be marked stable.
But then why was openoffice.org-2.1.0-r1 marked stable? Are more testers needed? Best regards Jan
Sorry for the *bad* English. I should go to bed now. :)
Exceptions have been made to those many times in the past when the stable tree is broken. To go by the book, masking or unstabling openoffice.org-2.1.0-r1 would seem to be the only option. To be clear, I don't mean to criticize. I'm simply being part of this community and stating my strong opinion that something needs to be done so that OOo works.
The patch seems to be working well for me. I've been building all day.
(In reply to comment #38) > But then why was openoffice.org-2.1.0-r1 marked stable? > Cause it fixes some security problems. Also 2.1.0 was in the tree way longer than 30 days and the STLport-problem didn't show up for the devs who tested it (I've never encountered it myself, too)
(In reply to comment #29) > ok, there have been two problems: > a) My local account does something weird: instead of setting CPPFLAGS to > "-D_...", it adds the contents of it to CFLAGS and then to CXXFLAGS. This was > the reason why the "-D_..." have always been added on my machine. > > b) STLport overrides the CPPFLAGS defined in the environment (see > build/Makefiles/gmake/gcc.mak). Extending the sed-line to replace CPPFLAGS in > the Makefile is the real solution and NOT adding the lfs-flags to CFLAGS and > CXXFLAGS. > > ... and please: If you don't have anything substantial to write, just don't > write it. I'm working hard and I'm working a lot and I don't get paid for it. > And committing a fix without knowing what the real problem was is bad and will > in 99% percent of the cases break things in the future. This appears to be in response to my comments, so I will respond. Sir, I meant no offense and I apologize. I was discussing my take on the situation with the involved group at the table. My comments were/are a valid point of view and not directed at you personally. They were not intended as a shot at you or anyone. I know as developer your projects are very personal to you. It is only natural for you to perceive that it is some kind of attack on you or your work, especially when you are working hard under stress and pressure. I am in the same boat as you in my own life friend. I apologize for and regret not stating this in a disclaimer of sorts as a prelude to the rest of my message. To clarify, what I _was_ doing was stating what I believed to be the magnitude of the current problem and a good temporary course of action. I realize that not fixing things "the best way" can break things and I myself am very much a stickler for doing things the _RIGHT WAY_ whenever possible. For this reason I did analyze and test the temporary fix quite thoroughly before recommending it myself. After testing, I was/am of the belief that this particular situation warranted the adoption of what seems to be a negligable-risk quick-fix that does not appear to break anything. So then I came an offered my input, not an order, based on my experience. From what I have seen the longer a bug like this goes unresolved, the more problems it creates. Even after the bug has been technically resolved and closed, time and effort will be spent by sys admins, users, bug-wranglers and others that could be better spent elsewhere. This is what I mean by "collective time", the total hours spent on an issue when adding the time of the entire group together. I was interested in limiting the amount of time this bug remained in portage, and thus the number of people who sync within this time window to as little as possible. I did feel that it was important that I state my input/recommendation so that official devs, such as yourself, may consider it. You as the dev are completely free to listen to my opinion and reject it. That is how it works. :) > So, if you think you can do better than me, why not become a dev yourself? You > can join #gentoo-cpp on irc.freenode.net for example and talk to me about it. > Writing an email is also a good idea. > I do not wish to get emotionally personal. I was not trying to tell you how to do your job, simply add my 2 cents as to what I believed would be the least-painful and collective-time-consuming course of action for the long term. I am not offended in the least should you choose otherwise. It is YOUR project, you have the final say and I respect that completely. I do not "think I am better than you" and did not mean to step on any toes. You do beautiful work and I do not want your job (my own is enough). My comments were not directed at you personally. In any case, you have my sincere apology and I hope we can work together in the future. Thank you sir for all your hard work, we all appreciate it very much.
Created attachment 115222 [details, diff] Improved patch to existing stable STLport-5.1.0.ebuild Sir, I believe this patch to be what you requested as the correct way to fix the problem. I propose that STLport-5.1.0 be rev-bumped with it and marked stable. -It allows openoffice-2.1.0 to build properly. -As openoffice-2.1.0 contains security fixes, masking it is undesireable at best. -STLport-5.1.0 has been stable quite awhile and this changes things only minimally rather than moving to version 5.1.2.
*** Bug 173112 has been marked as a duplicate of this bug. ***
Same Problem here. Portage 2.1.2.2 (default-linux/x86/2006.0, gcc-4.1.1, glibc-2.5-r0, 2.6.19-gentoo-r5 i686) ================================================================= System uname: 2.6.19-gentoo-r5 i686 AMD Athlon(tm) XP 2800+ Gentoo Base System version 1.12.9 Timestamp of tree: Mon, 02 Apr 2007 02:30:09 +0000 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.4 [disabled] dev-java/java-config: 1.3.7, 2.0.31-r5 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r6 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O3 -march=athlon-xp -fomit-frame-pointer -pipe -m3dnow -msse -mmmx" CHOST="i686-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/php/apache1-php5/ext-active/ /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O3 -march=athlon-xp -fomit-frame-pointer -pipe -m3dnow -msse -mmmx" DISTDIR="/usr/portage/distfiles" FEATURES="buildpkg distlocks fixpackages metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo http://ftp.roedu.net/pub/mirrors/gentoo.org/ http://ds.thn.htu.se/linux/gentoo http://mirror.switch.ch/ftp/mirror/gentoo/ http://ftp.snt.utwente.nl/pub/os/linux/gentoo http://ftp.lug.ro/gentoo/ ftp://ftp.nyx.hu/gentoo ftp://mirror.scarlet-internet.nl/pub/gentoo http://gentoo.po.opole.pl http://www.die.unipd.it/pub/Linux/distributions/gentoo-sources/ http://www.mirrorservice.org/sites/www.ibiblio.org/gentoo/ http://mirrors.evolva.ro/gentoo/ ftp://mirror.switch.ch/mirror/gentoo/ http://gentoo.prz.rzeszow.pl http://mirror.etf.bg.ac.yu/gentoo http://darkstar.ist.utl.pt/gentoo/ http://gentoo.ynet.sk/pub" LC_ALL="de_DE.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--sort-common -s" LINGUAS="de" MAKEOPTS="-j1" 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 --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/root/portage-overlay" SYNC="rsync://krotok/gentoo-portage/" USE="3dnow 3dnowext X aac alsa apm bcmath berkdb bitmap-fonts browserplugin calendar cli cracklib crypt ctype cups dba dri dts dv dvd dvdr dvdread eds emboss encode esd foomaticdb fortran ftp gd gdbm gif gimp gphoto2 gpm gtk gtk2 hal iconv ieee1394 imlib inifile ipod isdnlog jpeg kde kdeenablefinal libg++ libwww mad midi mikmod mime mmx motif mp3 mpeg mplayer mpm-worker msn ncurses nls nptl nptlonly nsplugin ogg opengl oss pam pcntl pcre pdf perl pic png pppd python qt3 qt4 quicktime readline real reflection samba sdl session simplexml soap sockets spell spl sqlite sse ssl startup-notification subtitles tcpd threads tidy tk tokenizer truetype truetype-fonts type1-fonts unicode usb vorbis wddx win32codecs x86 xine xinerama xml xmlrpc xorg xscreensaver xsl xv xvid yuv yv12 zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de" USERLAND="GNU" VIDEO_CARDS="radeon" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
x86 stable is still broken. ChangeLog: 01 Apr 2007; Tiziano Müller <dev-zero@gentoo.org> +files/STLport-5.1.2-wrong_russian_currency_name.patch, +STLport-5.1.2.ebuild: Version bump. Fixes bug #172860, thanks to Robin Johnson. AFAICS only 5.1.2 (~for all archs) is fixed, so either 5.1.2 needs stablising on all archs, or the earlier versions need to be fixed and revision bumped.
IMHO, 5.1.2 should not be stabled since it was added to the tree only yesterday. Please consider the corrected patch & proposal in comment #44. I believe it to be the least risky and most in line with Gentoo development policies. Not trying to step on any toes. I wish only to help. Thanks. :)
Guys, here is my 2 cents: To the build of OO belongs libdb-4.2.so. That file went, due to the failed build, missing on my server, which is set to autoupdate. That blew: - apache - postfix (all mail communication) - all mail clients - webmail client (due to apache) - fetchmail (due to postfix) - emerge (couldn't send emerge logs anymore due to postfix) - and so forth... Bottom line: the entire server went... Now I kept him offline, waiting for a fix... to be honest I am pretty disappointed it hasn't come... I have now upgrade TSLport, and that fixed it, but still i have to remember to take that package out of portage.keywords one day... That someone is actually suggesting to leave things as they are seems scary to me... whoever auto-updates can fluke his entire system, and there is nothing being done about it? they all supposed to find the bug, and manually upgrade TSL port? Wow!
Well, I also have this problem. My reasoning is that if OO depends on an unstable package it is unstable also. So either declare STLport-5.1.2 stable or let OO go back to unstable.
(In reply to comment #50) > Well, I also have this problem. > > My reasoning is that if OO depends on an unstable package > it is unstable also. So either declare STLport-5.1.2 stable > or let OO go back to unstable. > Completely agree, and this is one of the most critical packages for productivity. I also have the same problem.
Calm down, people. We're aware of the situation, and we're working on fixing it. Unfortunately, the fix involves stable keywording of a new version, which takes time due to the number of people that need to be involved.
Florian: there is something else wrong with your system. A failed compile of openoffice won't wreck apache etc. db libs are supplied by package sys-libs/db, not openoffice. The libs installed by openoffice should be used by openoffice only. Maybe you have accidentally added "/usr/lib/openoffice/program/" to /etc/ld.so.conf? The other obvious point is that this bug stops openoffice from compiling. Emerge never reaches the stage of merging the newly built openoffice with your live file system, so this bug can't be the source of your problems.
(In reply to comment #52) > ....Unfortunately, > the fix involves stable keywording of a new version, which takes time due to > the number of people that need to be involved. > I took Mr. Tiziano Müller criticism to heart and created a fix available in comment #44 for the current stable version exactly as he asked. It is written exactly to package standard as he requested. It just so happens the resulting output/package is exactly the same as our "rushed fix that was going to break everything". Now the plan is to stabilize a new version that was rushed into the tree and has not been there more than a day?
(In reply to comment #54) > Now the plan is to stabilize a new version that was rushed into the tree and > has not been there more than a day? Unfortunately it's not currently possible for an ebuild to depend upon version 5.1.0 or later of STLport which was installed from an ebuild that was downloaded on or after the third of april. If you think such functionality would be useful, producing a patch for Portage would probably be the next step to take. Alternatively, we could bump the version so that OpenOffice can depend upon a version of STLport which contains the fix.
*** Bug 173193 has been marked as a duplicate of this bug. ***
(In reply to comment #55) > (In reply to comment #54) > > Now the plan is to stabilize a new version that was rushed into the tree and > > has not been there more than a day? > > Unfortunately it's not currently possible for an ebuild to depend upon version > 5.1.0 or later of STLport which was installed from an ebuild that was > downloaded on or after the third of april. > I am sorry, I perhaps I do not understand what you are saying here? I propose bumping STLport-5.1.0 to STLport-5.1.0-r1 using the patch in comment #44 then bumping openoffice-2.1.0-r1 to -r2 to depend on STLport-5.1.0-r1. Both openoffice-2.1.0-r2 and STLport-5.1.0-r1 could be stabilized right away as the changes would be minimal. This option fixes the problem with the least possible risk of breaking anything that I can see.
Created attachment 115320 [details, diff] bump openoffice-2.1.0-r1 to -r2 and make it depend on STLport-5.1.0-r1 I really want to help in any way I can to help resolve this as soon as possible so if I am not understanding you correctly please help me to. Thank you.
(In reply to comment #57) > I am sorry, I perhaps I do not understand what you are saying here? I propose > bumping STLport-5.1.0 to STLport-5.1.0-r1 using the patch in comment #44 then > bumping openoffice-2.1.0-r1 to -r2 to depend on STLport-5.1.0-r1. Which still requires pushing an ebuild into stable that's only been in the tree for a day. We thought about doing 5.1.0-r1, but decided that it wasn't worth it for the two archs who have stable openoffice that need it.
(In reply to comment #59) > (In reply to comment #57) > > I am sorry, I perhaps I do not understand what you are saying here? I propose > > bumping STLport-5.1.0 to STLport-5.1.0-r1 using the patch in comment #44 then > > bumping openoffice-2.1.0-r1 to -r2 to depend on STLport-5.1.0-r1. > > Which still requires pushing an ebuild into stable that's only been in the tree > for a day. We thought about doing 5.1.0-r1, but decided that it wasn't worth it > for the two archs who have stable openoffice that need it. > Yes, but the difference is: STLport-5.1.0 was tested and then marked stable between Feb 13th-Mar 12th depending on arch. STLport-5.1.0-r1 has only the necessary fixes to allow openoffice-2.1.0 to build. STLport-5.1.2 was added yesterday, has the same fixes, but also new, untested code. If other archs can compile openoffice-2.1.0-r1 just fine, and do not require a revbump, we don't want to make them recompile it for -r2, so how about bumping openoffice-2.1.0-r1 to -r2 to depend on STLport-5.1.0-r1 then stabilizing it on only the arches the need it, such as x86?
(In reply to comment #60) > (In reply to comment #59) > > (In reply to comment #57) > > > I am sorry, I perhaps I do not understand what you are saying here? I propose > > > bumping STLport-5.1.0 to STLport-5.1.0-r1 using the patch in comment #44 then > > > bumping openoffice-2.1.0-r1 to -r2 to depend on STLport-5.1.0-r1. > > > > Which still requires pushing an ebuild into stable that's only been in the tree > > for a day. We thought about doing 5.1.0-r1, but decided that it wasn't worth it > > for the two archs who have stable openoffice that need it. > > > > Yes, but the difference is: > STLport-5.1.0 was tested and then marked stable between Feb 13th-Mar 12th > depending on arch. > STLport-5.1.0-r1 has only the necessary fixes to allow openoffice-2.1.0 to > build. > STLport-5.1.2 was added yesterday, has the same fixes, but also new, untested > code. > > If other archs can compile openoffice-2.1.0-r1 just fine, and do not require a > revbump, we don't want to make them recompile it for -r2, so how about bumping > openoffice-2.1.0-r1 to -r2 to depend on STLport-5.1.0-r1 then stabilizing it on > only the arches the need it, such as x86? > It would be quite enough to make STLport-5.1.0-r1 stable. It would make the new version to be installed and than even openoffice-2.1.0-r1 will compile everywhere. It won't be necessary to make a new version of openoffice ebuild, if the error is in STLport, IMHO. Regards, Dw.
I'm well aware of the difference. We decided to do it this way. It really doesn't make any difference to the time taken to resolve the problem.
(In reply to comment #62) > I'm well aware of the difference. We decided to do it this way. It really > doesn't make any difference to the time taken to resolve the problem. > You could've said that you were not entertaining any ideas outside your dev circle from the start and saved me a lot of time. I find it ironic that we were going to "break everything in our rush to patch STLport-5.1.0" and told to redesign the patch, now a version of STLport that was added to ~arch yesterday is going to be stabled. About there not being any difference in time to solve the problem.. it is already solved locally for many others, including myself and my workplace and there is still no fix in portage. Not flaming anyone, just pointing out the facts.
i'm not a developer by any means. However, I have tried to emerge --sync probably 3 or 4 times since the 30th of March. I decided to do a fully sync and emerge -avUd world and it got 2/3rd's of the way through and broke on compliling OpenOffice. The problem is, my gui is messed up now too. When I try to run a rev-dep rebuild it tries to emerge the older version of openoffice and then complains there is not an ebuild for the package. What this boils down to is, I cannot use my system anymore. I feel this is in many ways directly related to this bug. I can't, for the life of me, understand why the OpenOffice-2.1.0-r1 application was marked as stable. When the applications it depends on to compile right are marked unstable?? AGAIN I'M NO DEVELOPER. However, I know that I have been using gentoo off and on for 3 years, and things like this make it hard to want to continue to use it. This makes 3 bugs I've had in the last week, just from doing an emerge -avUd world on my system thats only emerging packages marked as stable for x86. I just don't understand...but its a pain and I probably won't update my system without reading the forumns first next time if this persists.
sorry, i meant to add in. It looks to me as though we need more testers. If that is the case, i'm actually looking at doing what I need to so that I can help test ebuilds. If that is going to help in the long run from preventing these types of issues. Are we just pressing to hard to get new releases out? Security fixes or not...
~x86 emerge STLport-5.1.2 emerge openoffice-2.1.0-r1 ------OK close this bugs please.
(In reply to comment #66) > ~x86 > emerge STLport-5.1.2 > emerge openoffice-2.1.0-r1 ------OK > > close this bugs please. > It is not fixed for x86/stable
*** Bug 173230 has been marked as a duplicate of this bug. ***
Ben: "I can't, for the life of me, understand why the OpenOffice-2.1.0-r1 application was marked as stable. When the applications it depends on to compile right are marked unstable??" It obviously shouldn't have been done that way. The developer stabilised without testing the compile under a clean x86 tree. Probably because openoffice takes so long to compile... "sorry, i meant to add in. It looks to me as though we need more testers. If that is the case, i'm actually looking at doing what I need to so that I can help test ebuilds." Good. Gentoo can always do with more people. There are only two developers in the open office herd... for a package the size and complexity of openoffice, that isn't enough.
(In reply to comment #69) > It obviously shouldn't have been done that way. The developer stabilised > without testing the compile under a clean x86 tree. Probably because openoffice > takes so long to compile... STLport-5.1.0 cvs rev1.2 enabled large file support and worked just fine. Though, some change to the flag-o-matic eclass disabled large file support silently for STLport. http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/flag-o-matic.eclass?r1=1.117&r2=1.118
(In reply to comment #69) > > Good. Gentoo can always do with more people. There are only two developers in > the open office herd... for a package the size and complexity of openoffice, > that isn't enough. Just as a sidepoint: Stabilizing is done by the respective arch-testers, so this particular situation has nothing at all to do with the OOo-herd not having enough devs. It's just an unfortunate situation of a package getting broken without revbump, so nobody recognized.
(In reply to comment #70) > (In reply to comment #69) > > It obviously shouldn't have been done that way. The developer stabilised > > without testing the compile under a clean x86 tree. Probably because openoffice > > takes so long to compile... > > STLport-5.1.0 cvs rev1.2 enabled large file support and worked just fine. > Though, some change to the flag-o-matic eclass disabled large file support > silently for STLport. > > http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/flag-o-matic.eclass?r1=1.117&r2=1.118 > Quite a find there! =O Anyway, looks like STLport-5.1.2 is in the processes of being stabled on the necessary archs and is already stable for x86. Thank you CPP devs.
(In reply to comment #63) > You could've said that you were not entertaining any ideas outside your dev > circle from the start and saved me a lot of time. I didn't say that, nor is it true. We considered patching 5.1.0, and decided that it was better to just push 5.1.2 to stable. Please start reading what I said, and stop drawing incorrect assumptions from what I didn't.
Created attachment 115547 [details] build.log with lots of nested includes
(In reply to comment #74) > Created an attachment (id=115547) [edit] > build.log with lots of nested includes > Don't know whether this is the same bug or a different one, but my oo-2.1.0-r1 fails as shown in the attached log. Please redirect me if this is an unrelated bug. I have STLport-5.1.2. ---------------- # emerge --info Portage 2.1.2.2 (default-linux/x86/2006.0, gcc-4.1.1, glibc-2.5-r0, 2.6.18.6 i686) ================================================================= System uname: 2.6.18.6 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz Gentoo Base System release 1.12.9 Timestamp of tree: Thu, 05 Apr 2007 23:50:01 +0000 dev-java/java-config: 1.3.7, 2.0.31 dev-lang/python: 2.3.5-r3, 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -mtune=pentium4 -Os -pipe" CHOST="i686-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/terminfo" CXXFLAGS="-march=pentium4 -mtune=pentium4 -Os -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks fixpackages metadata-transfer parallel-fetch sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="http://mirror.switch.ch/ftp/mirror/gentoo http://ftp.snt.ipv6.utwente.nl/pub/os/linux/gentoo http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo http://trumpetti.atm.tut.fi/gentoo http://ftp.heanet.ie/pub/gentoo http://darkstar.ist.utl.pt/gentoo http://gd.tuwien.ac.at/opsys/linux/gentoo http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" LC_ALL="en_GB.utf8" LINGUAS="en_GB" MAKEOPTS="-j2" 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 --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://ws-nessus/gentoo-portage" USE="X acpi aiglx alsa arts avi berkdb branding bzip2 bzlib cdr cracklib crypt cups dbm dga dio dlloader dri dvd dvdr encode exif extensions fam ffmpeg font-server foomaticdb ftp gdbm gif idn imap imlib inifile innodb ipv6 java jpeg kde kdeenablefinal kdehiddenvisibility kdexdeltas kerberos mad maildir mbox mcal mime mmap mmx mng motif mozbranding mp3 mpeg musepack ncurses nls nptl nptlonly nsplugin offensive ogg oggvorbis opengl pam pcntl pcre pda pdflib perl png posix ppds python qt qt3 quicktime rdesktop readline restrict-javascript samba sdl shared sharedmem slp sockets sse ssl svg sysvipc tcl tcltk threads tiff tk truetype truetype-fonts type1-fonts unicode usb userlocales vorbis win32codecs wmf x86 xine xml xml2 xmlrpc xorg xpm xsl xv xvid yahoo zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en_GB" USERLAND="GNU" VIDEO_CARDS="nvidia vga vesa fbdev" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS Thanks for any help
@Etaoin: That's another issue, see bug #163905 and the advice there.
(In reply to comment #76) > @Etaoin: That's another issue, see bug #163905 and the advice there. > Ah ok, many thanks. I sometimes forget to search among closed bugs also.
I'm glad to see things progressing along here. I really think that bumping STLport up to the stable tree is the way to go. If it helps us to speed things along at all, I tested STLport-5.1.2 (~x86) on my test machine and it emerged succesfully. I was also able to emerge openoffice with no problems at that point. Everything else seems stable at this point.. Including a full emerge of gnome and x11 after making those changes.
(In reply to comment #78) > I'm glad to see things progressing along here. I really think that bumping > STLport up to the stable tree is the way to go. > > If it helps us to speed things along at all, I tested STLport-5.1.2 (~x86) on > my test machine and it emerged succesfully. I was also able to emerge > openoffice with no problems at that point. Everything else seems stable at this > point.. Unless i sniffed too much glue STLport-5.1.2 seems to be stable on x86 already: http://packages.gentoo.org/search/?sstring=stlport
Umm...STLport-5.1.2 has been stable for days. :)
yeah, sorry! my bad! I know just a few days ago they were still debating whether to mark it as stable or not. I have an older system I do some of my testing with, so it took a while to get everything emerged and make sure STLport 5.1.2 is working okay.... Glad to see it!
All good stuff but shouldn't openoffice now be bumped to depend on STLport-5.1.2?
It's not really necessary. If it built for the person before there is no need to make the rebuild it. If they couldn't build it portage will emerge the STLport-5.1.2 first then attempt to build openoffice-2.1.0-r1.
(In reply to comment #82) > All good stuff but shouldn't openoffice now be bumped to depend on > STLport-5.1.2? > Not unless we want to break ppc (as they haven't stabilized STLport-5.1.2 until now) ;)
(In reply to comment #83) > It's not really necessary. If it built for the person before there is no need > to make the rebuild it. If they couldn't build it portage will emerge the > STLport-5.1.2 first then attempt to build openoffice-2.1.0-r1. > Only if STLport is in world which it wasn't in my case.
(In reply to comment #84) > (In reply to comment #82) > > All good stuff but shouldn't openoffice now be bumped to depend on > > STLport-5.1.2? > > > > Not unless we want to break ppc (as they haven't stabilized STLport-5.1.2 until > now) ;) > Ahh - sorry - missed that - I had the x86 filter goggles on :-) It does make things a bit awkward as >=STLport-5.1.2 is a dependency of this package, lets hope the ppc STLport package stabilizes soon. It's bound to catch out some people who haven't got STLport in their world file.
Hardly anyone should have STLport in their world file (I don't) it is usually brought in as a dependency and would be upgraded by emerge -uD world before openoffice. This is the way it has done it on every machine I have done it on so far (20+). I have theories as to why it probably didn't do that in your case but that is really forum/email conversation because it is off topic for this bug.
(In reply to comment #87) > Hardly anyone should have STLport in their world file (I don't) it is usually > brought in as a dependency and would be upgraded by emerge -uD world before > openoffice. This is the way it has done it on every machine I have done it on > so far (20+). I have theories as to why it probably didn't do that in your > case but that is really forum/email conversation because it is off topic for > this bug. > No mystery there - I usually just do an emerge world, I've been doing it this way for nearly five years and never had a problem until now (although a very minor problem). With proper dependency specifications in the packages this way should work just fine. My point is that openoffice now has a dependency on >=STLport-5.1.2 and it really should be marked as such. In fact to avoid the re-compilation for every one who has updated (including me) then just don't do a version bump, i.e. leave openoffice at 2.1.0-r1.
I've updated the STLport dep to 5.1.2 in the 2.1.0-r1 ebuild. We'll call this fixed until someone says otherwise.
While still using STLport, I simply replaced the append-lfs-flags line with append-flags -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE and OpenOffice build this time. Thanks to Hanno Meyer-Thurow
Oups! I meant, "... still using STLport-5.1.0 ..."
