# Openoffice 2.3

## AROK

Hallo zusammen,

nachdem mein Update von Openoffice 2.3 gestern nach etwa 2h abbrach  :Wink:  und ich heute die Lösung gefunden habe 

https://forums.gentoo.org/viewtopic-t-584594-highlight-gperf.html , dachte ich ich poste es mal hier dann könnt ihr euch das Problem sparen. Vielleicht ist es ja auch inzwischen gefixt. Das Problem war eine nicht eingetragene Abhängigkeit von gperf. Owohl es bei mir schon drauf war ?? hatte ich das Problem auch. Jedenfalls lief 

```
emerge openoffice
```

 es nach einem 

```
emerge --oneshot gperf
```

 ohne Probleme durch.

Gruß

AROK

Noch der Fehlertext, für die Suche:

```

=============

Building project oox

=============

/var/tmp/portage/app-office/openoffice-2.3.0/work/ooo/build/OOG680_m5/oox/source/token

mkout -- version: 1.7

/usr/bin/perl gentoken.pl tokens.txt ../../unxlngi6.pro/inc/tokens.hxx ../../unxlngi6.pro/misc/tokens.gperf

gperf --compare-strncmp --output-file=../../unxlngi6.pro/misc/_tokens.cxx ../../unxlngi6.pro/misc/tokens.gperf

dmake:  Error: -- gperf: No such file or directory

dmake:  Error code -1, while making '../../unxlngi6.pro/inc/tokens.cxx'

---* tg_merge.mk *---

ERROR: Error 65280 occurred while making /var/tmp/portage/app-office/openoffice-2.3.0/work/ooo/build/OOG680_m5/oox/source/token

make: *** [stamp/build] Error 1

 *

 * ERROR: app-office/openoffice-2.3.0 failed.

 * Call stack:

 *   ebuild.sh, line 1654:   Called dyn_compile

 *   ebuild.sh, line 990:   Called qa_call 'src_compile'

 *   ebuild.sh, line 44:   Called src_compile

 *   openoffice-2.3.0.ebuild, line 331:   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.3.0/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.12"

JAVACFLAGS="-source 1.4 -target 1.4" COMPILER=""

and of course, the output of emerge --info

```

----------

## ScytheMan

is schon bereits als dependency im ebuild. 

vermutlich lag dein sync irgendwo dazwischen.

hab 10 1/2 Stunden bauen lassen

----------

## AROK

Schön, dass es jetzt drin ist.

 *Quote:*   

> hab 10 1/2 Stunden bauen lassen

 

Hätte ich auch mal stoppen sollen, aber länger als 8h hats bei mir nicht gedauert.  Aber ein Mehrprozessorsystem wird dabei eh schlecht ausgelastet. Die Meiste Zeit arbeitet nur eine CPU. Oder mach ich was falsch?

----------

## musv

 *AROK wrote:*   

> 
> 
> Hätte ich auch mal stoppen sollen, aber länger als 8h hats bei mir nicht gedauert.

 

```

[I] app-portage/splat

     Available versions:  0.07 0.08

     Installed versions:  0.08(23:54:23 04.03.2007)

     Homepage:            http://www.l8nite.net/projects/splat/

     Description:         Simple Portage Log Analyzer Tool

```

Und dann:

```

 splat openoffice

* app-office/openoffice-2.2.0

        Emerged at: Mi Apr 18 01:31:50 2007

        Build time: 8 hours, 20 minutes, and 24 seconds

```

----------

## ScytheMan

 *musv wrote:*   

>  *AROK wrote:*   
> 
> Hätte ich auch mal stoppen sollen, aber länger als 8h hats bei mir nicht gedauert. 
> 
> ```
> ...

 

Gibts bei dem Programm erweiterte Funktionen als unter genlop oder sind die weitestgehend funktionsgleich?

gruß ScytheMan

----------

## AmonAmarth

ich versteh bis heute nicht warum man sich die kompilierungs tortour antut wenn man doch sofort die binary nehmen kann!

klar ist das nicht die gentoo philosophie, aber openoffice-bin ist in dem fall doch wirklich genauso funktional...

----------

## hoschi

Da die Binary schon mal die falschen Icons für Gnome verwendet und deswegen auch ziemlich hässlich ausschaut, und weil es dem PRINZIP von Gentoo widerspricht. Mein Firefox ärgert mich durch die grausige Anpassung an GTK auch immer wieder.

Hauptgrund OpenOffice zu kompilieren sind die hässlichen Icons in der Binary   :Embarassed: 

----------

## _eckobar_

 *AROK wrote:*   

> Schön, dass es jetzt drin ist.
> 
>  *Quote:*   hab 10 1/2 Stunden bauen lassen 
> 
> Hätte ich auch mal stoppen sollen, aber länger als 8h hats bei mir nicht gedauert.  Aber ein Mehrprozessorsystem wird dabei eh schlecht ausgelastet. Die Meiste Zeit arbeitet nur eine CPU. Oder mach ich was falsch?

 

Bei einer Kompilierung werden bei mir eigentlich beide Kerne sehr schön gleichmäßig belastet. Openoffice hat bei mir auch nur ~3h gebraucht. Hast Du auch die MAKEOPTS richtig gesetzt bzw. Compiler-Flags für deine CPU optimiert?

 *AmonAmarth wrote:*   

> ich versteh bis heute nicht warum man sich die kompilierungs tortour antut wenn man doch sofort die binary nehmen kann!
> 
> klar ist das nicht die gentoo philosophie, aber openoffice-bin ist in dem fall doch wirklich genauso funktional...

 

damit der core2duo mal ins schwitzen kommt *gg*

----------

## Aldo

Bekommt man OpenOffice denn mittlerweile native für 64Bit kompiliert?

Das ist der Grund weshalb ich Openoffice-bin nehme(n muss).

Und ich möchte jetzt nicht sundenlang warten um zu sehen daß es wieder abbricht beim bauen.

----------

## TheCurse

Also hier kompiliert es nicht (native 64bit), hatte aber auch noch nicht die Zeit mir mal die Fehlermeldung vorzunehmen und ggf. Bugreports zu durchwühlen bzw. zu erstellen.

----------

## Daimos

Bei mir baut er ohne Mucken nativ auf 64 bit durch (~amd64).

Es sind aber auch beim 2.3er kaum Passagen, wo beide Kerne meines X2 belastet werden - unterm Strich holt der vielleicht 10 Minuten damit raus.

Sieht aber hübscher aus, als die bin - und zwar bedeutend, was men Grund ist, das Ding aus den Quellen zu backen.

----------

## TheCurse

Gib doch mal nen emerge --info raus, vielleicht finde ich ja etwas, warum er bei mir nicht baut

----------

## UTgamer

Bei mir ist OpenOffice in 64 Bit wie immer gut durchgelaufen. 2.3 (64 Bit) startet sogar noch schneller als 2.2 welches schon sehr schnell startete.

@ TheCurse, hier mein emerge info

```
emerge --info

Portage 2.1.3.9 (default-linux/amd64/2007.0, gcc-4.1.2, glibc-2.5-r4, 2.6.22-gentoo-r2 x86_64)

=================================================================

System uname: 2.6.22-gentoo-r2 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+

Timestamp of tree: Sat, 22 Sep 2007 09:00:01 +0000

ccache version 2.4 [enabled]

app-shells/bash:     3.2_p17

dev-java/java-config: 1.3.7, 2.0.33-r1

dev-lang/python:     2.4.4-r5

dev-python/pycrypto: 2.0.1-r6

dev-util/ccache:     2.4-r7

sys-apps/baselayout: 1.12.9-r2

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.17-r1

sys-devel/gcc-config: 1.3.16

sys-devel/libtool:   1.5.24

virtual/os-headers:  2.6.21

ACCEPT_KEYWORDS="amd64"

CBUILD="x86_64-pc-linux-gnu"

CFLAGS="-march=athlon64 -O2 -mmmx -m3dnow -msse -msse3 -mfpmath=sse,387 -pipe -ffast-math -m64"

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/share/X11/xkb /usr/share/config"

CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c"

CXXFLAGS="-march=athlon64 -O2 -mmmx -m3dnow -msse -msse3 -mfpmath=sse,387 -pipe -ffast-math -m64"

DISTDIR="/usr/portage/distfiles"

EMERGE_DEFAULT_OPTS="--with-bdeps=y"

FEATURES="ccache distlocks sandbox sfperms strict unmerge-orphans userfetch"

GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo/ ftp://gd.tuwien.ac.at/opsys/linux/gentoo/  http://gentoo.inode.at/"

LANG="de_DE@euro"

LC_ALL="de_DE@euro"

LINGUAS="de"

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="/var/tmp"

PORTDIR="/usr/portage"

PORTDIR_OVERLAY="/usr/local/portage /usr/portage/local/layman/gnustep"

SYNC="rsync://rsync.gentoo.org/gentoo-portage"

USE="3dnow 3dnowext X Xaw3d aac aalib acl alsa amd amd64 apache2 apm audiofile avi bitmap-fonts browserplugin bzip2 cdparanoia cdr cgi cli cracklib cups dga directfb divx4linux doc dri dv dvb dvd dvdr dvdread encode fbcon ffmpeg fftw flac flash fontconfig foreign-package fortran freetype ftp gdbm gif glut gnustep gpm hal icq ieee1394 imagemagick imlib isdnlog jack javascript joystick jpeg ladcca lcms leim libg++ libwww lm_sensors mad midi mikmod mime mmx mng modplug motif mozilla moznomail mp3 mpeg mudflap nas ncurses nls nosendmail nptl nptlonly nsplugin nvidia oav ogg oggvorbis ooo-kde openal opengl openmp opie osc oss pam pcre perl png portaudio posix pppd profile python qt qtmt quicktime readline reflection rp-pppoe samba sasl scanner sdl seamonkey session shorten simplexml skins slang sndfile sockets socks5 sox speex spell spl sse sse2 sse3 ssl tcpd tetex tiff truetype truetype-fonts type1-fonts usb v4l vcd videos vorbis wxwindows xface xine xinerama xml xml2 xorg 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 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="de" USERLAND="GNU" VIDEO_CARDS="nvidia vesa"

Unset:  CTARGET, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
```

Und hier noch meine Kompilierzeiten:  :Very Happy: 

```
genlop -it openoffice

 * app-office/openoffice

     Mon Jun 11 09:03:58 2007 >>> app-office/openoffice-2.2.0

       merge time: 5 hours, 28 minutes and 35 seconds.

     Wed Jun 13 10:27:14 2007 >>> app-office/openoffice-2.2.1

       merge time: 6 hours, 31 minutes and 7 seconds.

     Mon Aug 13 21:32:18 2007 >>> app-office/openoffice-2.2.1

       merge time: 6 hours, 45 minutes and 54 seconds.

     Sun Sep 23 03:54:27 2007 >>> app-office/openoffice-2.3.0

       merge time: 5 hours, 15 minutes and 18 seconds.

   Total builds: 4

   Global build time: 1 day and 54 seconds.

   Average merge time: 6 hours and 13 seconds.

   Info about currently installed ebuild:

   * app-office/openoffice-2.3.0

   Install date: Sun Sep 23 03:54:27 2007

   USE="cups pam seamonkey -binfilter -cairo -dbus -debug -eds -firefox -gnome -gstreamer -gtk -kde -ldap -mono -sound -odk -webdav -xulrunner"

   CFLAGS="-march=athlon64 -O2 -mmmx -m3dnow -msse -msse3 -mfpmath=sse,387 -pipe -ffast-math -m64"
```

Hat jemand Erfahrung wie OO mit cairo zusammen läuft? Wenn sich das lohnt, dann würde ich es direkt nochmal mit kompilieren.

PS: Habe das Ebuild wie immer so umgestellt gehabt das es sowohl mit den Kompileroptionen -ffastmath als auch -m64 gebaut wurde. 

So ~ das einzige was diese Flags nicht mag ist Wine bis auf genau 3 etwas ältere Versionen. Die letzte Wineversion die diese Flags auch unterstützt war: app-emulation/wine-0.9.42.

 :Wink: 

----------

## dertobi123

 *Daimos wrote:*   

> Bei mir baut er ohne Mucken nativ auf 64 bit durch (~amd64).

 

dito

 *Daimos wrote:*   

> Es sind aber auch beim 2.3er kaum Passagen, wo beide Kerne meines X2 belastet werden - unterm Strich holt der vielleicht 10 Minuten damit raus.

 

OpenOffice ist da recht fragil, weshalb paralleles Build per default deaktiviert ist. Mit WANT_MP="true" emerge openoffice lässt sich ein paralleles Build aktivieren.

----------

## Daimos

In der Tat - wenn ich es parallel erzwinge, geht es kaum reproduzierbar in die Binsen. 

Macht wohl doch Sinn, paralleles Backen einzuschränken  :Wink: 

----------

## TheCurse

Scheinbar hat openoffice auch was gegen gcc-4.2.0, denn damit kompiliert es nicht, mit dem 4.1.2 schon.

----------

## Aldo

Hab es jetzt auch selbst gebaut.

Hat 10,5 Stunden gedauert.

Und sieht wirklich besser aus als das Bin.

Im ersten Anlauf hat es zwar gemeckert wegen meiner CFlags, aber mit CFLAGS="-march=opteron -mtune=opteron -O2 -fomit-frame-pointer -pipe"

lief es dann durch.

----------

## s.hase

 *TheCurse wrote:*   

> Scheinbar hat openoffice auch was gegen gcc-4.2.0, denn damit kompiliert es nicht, mit dem 4.1.2 schon.

 

Stimmt so pauschal nicht, OO compiliert und läuft bei mir unter amd64 mit gcc-4.2.0 ohne Probleme   :Wink: 

```

sulaco ~ # emerge --info

Portage 2.1.3.9 (default-linux/amd64/2007.0/desktop, gcc-4.2.0, glibc-2.6-r0, 2.6.22-gentoo-r7 x86_64)

=================================================================

System uname: 2.6.22-gentoo-r7 x86_64 AMD Athlon(tm) 64 Processor 3800+

Timestamp of tree: Sun, 23 Sep 2007 18:00:01 +0000

app-shells/bash:     3.2_p17

dev-java/java-config: 1.3.7, 2.0.33-r1

dev-lang/python:     2.4.4-r5

dev-python/pycrypto: 2.0.1-r6

sys-apps/baselayout: 1.12.9-r2

sys-apps/sandbox:    1.2.17

sys-devel/autoconf:  2.13, 2.61-r1

sys-devel/automake:  1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10

sys-devel/binutils:  2.18

sys-devel/gcc-config: 1.3.16

sys-devel/libtool:   1.5.24

virtual/os-headers:  2.6.22-r2

ACCEPT_KEYWORDS="amd64"

CBUILD="x86_64-pc-linux-gnu"

CFLAGS="-march=athlon64 -O2 -pipe -msse3 -ftree-vectorize -mfpmath=sse,387"

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/share/X11/xkb /usr/share/config"

CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo"

CXXFLAGS="-march=athlon64 -O2 -pipe -msse3 -ftree-vectorize -mfpmath=sse,387"

DISTDIR="/usr/portage/distfiles"

FEATURES="distlocks metadata-transfer parallel-fetch prelink sandbox sfperms strict unmerge-orphans userfetch userpriv usersandbox"

GENTOO_MIRRORS="ftp://ftp.tu-clausthal.de/pub/linux/gentoo/ ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/"

LANG="de_DE.utf8"

LC_ALL="de_DE.utf8"

LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--sort-common -Wl,--hash-style=both"

LINGUAS="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/overlays/xeffects /usr/local/overlays/gechi /usr/local/overlays/mpd /usr/local/overlays/portato /usr/local/portage"

SYNC="rsync://rsync.gentoo.org/gentoo-portage"

USE="3dnow 3dnowext X acl acpi alsa amd64 berkdb bitmap-fonts cairo cdr cli cracklib crypt cups dbus dri dvd dvdr dvdread eds emboss encode evo fam firefox fortran gdbm gif gpm gstreamer gtk hal iconv isdnlog jpeg kde kdeenablefinal kdehiddenvisibility kerberos mad midi mikmod mmx mmxext mp3 mpeg mudflap ncurses nls nptl nptlonly ogg opengl openmp oss pam pcre pdf perl pertty pic png pppd python qt3 qt3support qt4 quicktime readline reflection sdl session spell spl sse sse2 ssl ssse3 svg tcpd tiff truetype truetype-fonts type1-fonts unicode vorbis xml xorg xv zlib" ALSA_CARDS="emu10k1 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 evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de" USERLAND="GNU" VIDEO_CARDS="nv nvidia"

Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

```

----------

## Daimos

lüppt hier auch wunderbar mit dem 4.2er

```
daimos ~ # emerge --info

Portage 2.1.3.9 (default-linux/amd64/2007.0, gcc-4.2.0, glibc-2.6.1-r0, 2.6.22-gentoo-r4 x86_64)

=================================================================

System uname: 2.6.22-gentoo-r4 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+

Timestamp of tree: Sun, 23 Sep 2007 13:30:01 +0000

app-shells/bash:     3.2_p17-r1

dev-java/java-config: 1.3.7, 2.0.33-r1

dev-lang/python:     2.5.1-r2

dev-python/pycrypto: 2.0.1-r6

sys-apps/baselayout: 1.12.10-r4

sys-apps/sandbox:    1.2.18.1

sys-devel/autoconf:  2.13, 2.61-r1

sys-devel/automake:  1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10

sys-devel/binutils:  2.18

sys-devel/gcc-config: 1.4.0-r2

sys-devel/libtool:   1.5.24

virtual/os-headers:  2.6.22-r2

ACCEPT_KEYWORDS="amd64 ~amd64"

CBUILD="x86_64-pc-linux-gnu"

CFLAGS="-march=k8 -O3 -pipe -fomit-frame-pointer -fforce-mem -funroll-loops -ftracer -s -w"

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/share/X11/xkb /usr/share/config"

CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d"

CXXFLAGS="-march=k8 -O3 -pipe -fomit-frame-pointer -fforce-mem -funroll-loops -ftracer -s -w"

DISTDIR="/usr/portage/distfiles"

FEATURES="distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch"

GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo"

LANG="de_DE.utf8"

LC_ALL="de_DE.utf8"

LINGUAS="de"

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="/var/tmp"

PORTDIR="/usr/portage"

SYNC="rsync://rsync.gentoo.org/gentoo-portage"

USE="3dnow 3dnowext X acl acpi additions alsa amd64 bitmap-fonts cdr cli cracklib crypt css cups dbus dga dri dvd dvdr dvdread encode ffmpeg flac flash foomatic gdbm hal iconv java jpeg kde lm_sensors mad midi mime mmx mmxext mp3 mplayer mudflap ncurses nls nptl nptlonly ntfs ogg opengl openmp pam pcre pdf perl png ppds pppd python qt qt3 quicktime readline reiserfs sasl sensord smp spl sse sse2 ssl svcd tcpd tiff truetype truetype-fonts type1-fonts unicode utf-8 utf8 vboxbfe vcd videos vorbis wma wmf xcomposite xfs xorg xvid ~x86" ALSA_CARDS="emu10k1" 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="de" USERLAND="GNU" VIDEO_CARDS="nvidia"

Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY

```

genlop -t openoffice spuckt mir folgendes aus:

```
 Fri Sep 21 06:19:52 2007 >>> app-office/openoffice-2.3.0

       merge time: 4 hours, 58 minutes and 41 seconds.

```

Dauerte ungefähr ne halbe Stunde länger als beim 2.2.1er, allerdings hab ich dabei mit dem System auch ne Menge nebenbei gemacht.

----------

## LunX

```
app-office/openoffice-2.3.0

        Emerged at: Do Sep 20 19:26:24 2007

        Build time: 4 hours, 8 minutes, and 34 seconds

```

Bei mir läuft soweit alles wunderbar ohne Fehler.

----------

## UTgamer

 *Daimos wrote:*   

> lüppt hier auch wunderbar mit dem 4.2er
> 
> ```
> daimos ~ # emerge --info
> 
> ...

 

Ok, bei gleichem Prozessor aber gcc-4.2.0 bist du eben rund 17 Minuten schneller.

Dann habe ich keine Bedenken wenn gcc-4.2.0 Standard wird.  :Smile: 

Ich habe noch das allerste damals brandneue 3800+ System mit DDR-400 RAMs, also weder AM2 Chipsatz noch DDR 667 oder so etwas, wie die neuen Systeme verwenden, auch spielt hier die Festplattendurchsatzgeschwindigkeit eine Rolle. Mein System ist eben schon über 2 Jahre alt.  :Wink: 

----------

## s.hase

 *UTgamer wrote:*   

> 
> 
> Ok, bei gleichem Prozessor aber gcc-4.2.0 bist du eben rund 17 Minuten schneller.
> 
> Dann habe ich keine Bedenken wenn gcc-4.2.0 Standard wird. 
> ...

 

Mit einem Athlon64 3800+ Single Core und DDR-333   :Cool: 

 *Quote:*   

> 
> 
> System uname: 2.6.22-gentoo-r7 x86_64 AMD Athlon(tm) 64 Processor 3800+
> 
> Tue Sep 18 22:57:47 2007 >>> app-office/openoffice-2.3.0
> ...

 

----------

## UTgamer

@s.hase, wenn ich mir deine cflags anschaue,

 *Quote:*   

> CFLAGS="-march=athlon64 -O2 -pipe -msse3 -ftree-vectorize -mfpmath=sse,387" 

 

muß ich doch direkt mal nachschauen was -ftree-vectorize macht wenn openoffice sich auch damit sauber kompilieren läßt.  :Very Happy: 

----------

## Daimos

hm, sollte ein single core 3800+ da nicht unterm strich flotter sein, weil höher getaktet?

die zusätzliche core des X2 3800+ verpufft ja normalerweise. ich hab übrigens auch "nur" DDR400 - DDR2 find ich aufgrund der Latenzen unterm Strich sinnfrei.

----------

## Waiman

Hallo alle zusammen.

Bin neu hier und bei Gentoo-amd64 (ca. 1 Woche). Bisher verlief alles reibungslos: installieren, bootstrapen aus stage3, Desktop kompilieren, ... 

Aber mein OpenOffice will nicht. Da ich wie man sieht keine exotischen Flags benutze wundert mich das, wenn ich lese, dass es bei euch hinhaut.   :Sad: 

```
Portage 2.1.3.9 (default-linux/amd64/2007.0, gcc-4.1.2, glibc-2.5-r4, 2.6.22-gentoo-r5 x86_64)

=================================================================

System uname: 2.6.22-gentoo-r5 x86_64 AMD Athlon(tm) 64 Processor 3200+

Timestamp of tree: Mon, 24 Sep 2007 06:50:01 +0000

ccache version 2.4 [enabled]

app-shells/bash:     3.2_p17

dev-java/java-config: 1.3.7, 2.0.33-r1

dev-lang/python:     2.4.4-r4

dev-python/pycrypto: 2.0.1-r6

dev-util/ccache:     2.4-r7

sys-apps/baselayout: 1.12.9-r2

sys-apps/sandbox:    1.2.17

sys-devel/autoconf:  2.13, 2.61-r1

sys-devel/automake:  1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10

sys-devel/binutils:  2.17-r1

sys-devel/gcc-config: 1.3.16

sys-devel/libtool:   1.5.24

virtual/os-headers:  2.6.21

ACCEPT_KEYWORDS="amd64"

CBUILD="x86_64-pc-linux-gnu"

CFLAGS="-O2 -march=athlon64 -sse3 -finline-functions -pipe"

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/share/X11/xkb /usr/share/config"

CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c"

CXXFLAGS="-O2 -march=athlon64 -sse3 -finline-functions -pipe"

DISTDIR="/usr/portage/distfiles"

FEATURES="ccache distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch"

GENTOO_MIRRORS="http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo "

LANG="de_DE.UTF-8"

LC_ALL="de_DE.UTF-8"

LINGUAS="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="/tmp"

PORTDIR="/usr/portage"

PORTDIR_OVERLAY="/home/fred/portage"

SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"

USE="3dnow 3dnowext X a52 aac acl acpi akode alsa amd64 arts audiofile berkdb bitmap-fonts bzip2 cairo cddb cdparanoia cdr cli cracklib crypt cups custom-cflags dbus de divx doc dri dts dv dvd dvdnav dvdr dvdread dxr3 enca encode expat fame ffmpeg flac foomaticdb fortran ftp gdbm ggi gif gimpprint glitz gpm graphviz gs gstreamer gtk gtk2 gtkhtml hal iconv imagemagick imlib isdnlog jack java joystick jpeg jpeg2k kde kdeenablefinal lame lcms libcaca live livecd lm_sensors lua lzo mad md5sum midi mikmod mjpeg mmap mmx mmxext mng modplug mp2 mp3 mp4 mpeg mudflap musepack musicbrainz mysql ncurses nis nls nptl nptlonly odbc ogg openal openexr opengl openmp pam pcre pdf perl physfs png pnm postgres povray pppd python qt3 qt4 quicktime radio rar rdesktop readline realmedia reflection rtc rts sdl sensord session snmp speex spell spl sqlite sqlite3 srt sse sse2 sse3 ssl svg tcpd tga theora threads tiff truetype truetype-fonts type1-fonts unicode vcd visualization vorbis wavpack wmf wmp x264 xanim xine xml xorg xv xvid yv12 zlib" ALSA_CARDS="emu10k1" 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 wacom" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de" USERLAND="GNU" VIDEO_CARDS="radeon fglrx vesa"

Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
```

das Ende vom emerge-log:

```
Making: ../unxlngx6.pro/lib/libsb680lx.so

g++ -Wl,-z,combreloc -Wl,-z,defs -Wl,-rpath,'$ORIGIN' -shared -L../unxlngx6.pro/lib -L../lib -L/tmp/portage/app-office/openoffice-2.3.0/work/ooo/build/OOG680_m5/solenv/unxlngx6/lib -L/tmp/portage/app-office/openoffice-2.3.0/work/ooo/build/OOG680_m5/solver/680/unxlngx6.pro/lib -L/tmp/portage/app-office/openoffice-2.3.0/work/ooo/build/OOG680_m5/solenv/unxlngx6/lib -L/opt/blackdown-jdk-1.4.2.03/lib64 -L/opt/blackdown-jdk-1.4.2.03/jre/lib/amd64 -L/opt/blackdown-jdk-1.4.2.03/jre/lib/amd64/server -L/opt/blackdown-jdk-1.4.2.03/jre/lib/amd64/native_threads -L/usr/lib64 ../unxlngx6.pro/slo/sb_dflt_version.o -o ../unxlngx6.pro/lib/libsb680lx.so ../unxlngx6.pro/slo/basmgr.o ../unxlngx6.pro/slo/basicmanagerrepository.o ../unxlngx6.pro/slo/sb.o ../unxlngx6.pro/slo/sbxmod.o ../unxlngx6.pro/slo/image.o ../unxlngx6.pro/slo/sbintern.o ../unxlngx6.pro/slo/sbunoobj.o ../unxlngx6.pro/slo/propacc.o ../unxlngx6.pro/slo/disas.o ../unxlngx6.pro/slo/errobject.o ../unxlngx6.pro/slo/eventatt.o ../unxlngx6.pro/slo/sbcomp.o ../unxlngx6.pro/slo/dim.o ../unxlngx6.pro/slo/exprtree.o ../unxlngx6.pro/slo/exprnode.o ../unxlngx6.pro/slo/exprgen.o ../unxlngx6.pro/slo/codegen.o ../unxlngx6.pro/slo/io.o ../unxlngx6.pro/slo/loops.o ../unxlngx6.pro/slo/parser.o ../unxlngx6.pro/slo/scanner.o ../unxlngx6.pro/slo/token.o ../unxlngx6.pro/slo/symtbl.o ../unxlngx6.pro/slo/buffer.o ../unxlngx6.pro/slo/namecont.o ../unxlngx6.pro/slo/scriptcont.o ../unxlngx6.pro/slo/dlgcont.o ../unxlngx6.pro/slo/sbmodule.o ../unxlngx6.pro/slo/sbservices.o ../unxlngx6.pro/slo/modsizeexceeded.o ../unxlngx6.pro/slo/basrdll.o ../unxlngx6.pro/slo/inputbox.o ../unxlngx6.pro/slo/runtime.o ../unxlngx6.pro/slo/step0.o ../unxlngx6.pro/slo/step1.o ../unxlngx6.pro/slo/step2.o ../unxlngx6.pro/slo/iosys.o ../unxlngx6.pro/slo/stdobj.o ../unxlngx6.pro/slo/stdobj1.o ../unxlngx6.pro/slo/methods.o ../unxlngx6.pro/slo/methods1.o ../unxlngx6.pro/slo/props.o ../unxlngx6.pro/slo/ddectrl.o ../unxlngx6.pro/slo/dllmgr.o ../unxlngx6.pro/slo/sbxbase.o ../unxlngx6.pro/slo/sbxres.o ../unxlngx6.pro/slo/sbxvalue.o ../unxlngx6.pro/slo/sbxvals.o ../unxlngx6.pro/slo/sbxvar.o ../unxlngx6.pro/slo/sbxarray.o ../unxlngx6.pro/slo/sbxobj.o ../unxlngx6.pro/slo/sbxcoll.o ../unxlngx6.pro/slo/sbxexec.o ../unxlngx6.pro/slo/sbxint.o ../unxlngx6.pro/slo/sbxlng.o ../unxlngx6.pro/slo/sbxsng.o ../unxlngx6.pro/slo/sbxmstrm.o ../unxlngx6.pro/slo/sbxdbl.o ../unxlngx6.pro/slo/sbxcurr.o ../unxlngx6.pro/slo/sbxdate.o ../unxlngx6.pro/slo/sbxstr.o ../unxlngx6.pro/slo/sbxbool.o ../unxlngx6.pro/slo/sbxchar.o ../unxlngx6.pro/slo/sbxbyte.o ../unxlngx6.pro/slo/sbxuint.o ../unxlngx6.pro/slo/sbxulng.o ../unxlngx6.pro/slo/sbxform.o ../unxlngx6.pro/slo/sbxscan.o ../unxlngx6.pro/slo/sbxdec.o -luno_cppu -luno_cppuhelpergcc3 -ltl680lx -lsvt680lx -lsvl680lx -lvcl680lx -lvos3gcc3 -luno_sal -lcomphelp4gcc3 -lutl680lx -lsot680lx -lvos3gcc3 -lxcr680lx -ldl -lpthread -lm -Wl,-Bdynamic -lstlport_gcc

../unxlngx6.pro/slo/image.o: In function `SbiImage::Load(SvStream&, unsigned int&)':

image.cxx:(.text+0x7b9): undefined reference to `PCodeBuffConvertor<unsigned short, unsigned int>::convert()'

image.cxx:(.text+0x7c3): undefined reference to `PCodeBuffConvertor<unsigned short, unsigned int>::convert()'

../unxlngx6.pro/slo/image.o: In function `SbiImage::Save(SvStream&, unsigned int)':

image.cxx:(.text+0x1554): undefined reference to `PCodeBuffConvertor<unsigned int, unsigned short>::convert()'

image.cxx:(.text+0x155e): undefined reference to `PCodeBuffConvertor<unsigned int, unsigned short>::convert()'

collect2: ld returned 1 exit status

dmake:  Error code 1, while making '../unxlngx6.pro/lib/libsb680lx.so'

---* tg_merge.mk *---

ERROR: Error 65280 occurred while making /tmp/portage/app-office/openoffice-2.3.0/work/ooo/build/OOG680_m5/basic/util

make: *** [stamp/build] Error 1
```

und so hab' ich's gemacht:

```

echo "app-office/openoffice ~amd64" >> /etc/portage/package.keywords

USE="cups pam -seamonkey -binfilter -cairo -dbus -debug -eds -firefox -gnome -gstreamer -gtk -kde -ldap -mono -sound -odk -webdav -xulrunner" emerge -pv openoffice

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild  N    ] app-office/openoffice-2.3.0  USE="cups java pam -binfilter -cairo -dbus -debug -eds -firefox -gnome -gstreamer -gtk -kde -ldap -mono -odk -seamonkey -sound -webdav -xulrunner" LINGUAS="de -af -ar -as_IN -be_BY -bg -bn -br -bs -ca -cs -cy -da -dz -el -en -en_GB -en_US -en_ZA -eo -es -et -fa -fi -fr -ga -gl -gu_IN -he -hi_IN -hr -hu -it -ja -km -ko -ku -lt -lv -mk -ml_IN -mr_IN -nb -ne -nl -nn -nr -ns -or_IN -pa_IN -pl -pt -pt_BR -ru -rw -sh_YU -sk -sl -sr_CS -ss -st -sv -sw_TZ -ta_IN -te_IN -tg -th -ti_ER -tn -tr -ts -uk -ur_IN -ve -vi -xh -zh_CN -zh_TW -zu" 0 kB

```

Merkwürdig daran ist, dass es keine externe Abhängikeit ist die nicht erfüllt wird, sondern eine interne.

Einer 'ne Idee? Danke.

----------

## Waiman

Beim erstellen eines Bug-Reports auf https://bugs.gentoo.org/ bin ich über ähnliches gestolpert.

-finline-functions scheint nicht das flag der Wahl zu sein wenn es um openoffice geht.

Also ab in die nächste Runde...

----------

## s.hase

 *Daimos wrote:*   

> hm, sollte ein single core 3800+ da nicht unterm strich flotter sein, weil höher getaktet?
> 
> die zusätzliche core des X2 3800+ verpufft ja normalerweise. ich hab übrigens auch "nur" DDR400 - DDR2 find ich aufgrund der Latenzen unterm Strich sinnfrei.

 

Naja, ich habe nebenbei schon ordentlich gearbeitet. Eclipse auf, Apache + MySQL rennt, ein paar kleinere Sachen compiliert usw. Das wird wahrscheinlich schon was ausgemacht haben. Dazu kommt das beim compilieren von OO zwar nur ein Kern benutzt wird, der andere Kern aber ja vom System für andere Sachen genutzt werden kann.

----------

## Aldo

 *UTgamer wrote:*   

> muß ich doch direkt mal nachschauen was -ftree-vectorize macht wenn openoffice sich auch damit sauber kompilieren läßt. 

 

Damit können automatisch SSE-Befehle des Prozessors genutzt werden um mehrere Daten mit einer Operation gleichzeitig zu verarbeiten.

----------

## Ampheus

Zu den schöneren Icons: Hat einer von euch mal einen screenshot, damit ich mal vergleichen kann? Ich hab nämlich nicht die bin, sondern aus Quellen installiert und finde die Icons grässlich. Vielleicht liegt es ja an einem USE-Flag.

----------

## Aldo

 *Ampheus wrote:*   

> Zu den schöneren Icons: Hat einer von euch mal einen screenshot, damit ich mal vergleichen kann? Ich hab nämlich nicht die bin, sondern aus Quellen installiert und finde die Icons grässlich. Vielleicht liegt es ja an einem USE-Flag.

 

Bei mir sieht es so aus:

http://www.imageshost.de/img.php?id=596eda216a81f5d

----------

## Ampheus

So sieht es bei mir auch aus. Heißt das, bei der bin sind die Icons noch hässlicher oder besser gesagt "unpassender"?

Ich finde, obwohl ich MS nicht leiden kann, ist Office 2007 sehr gut geworden. Die Icons sind da viel übersichtlicher und das Programm ist um einiges besser zu bedienen. Da kann sich OOo noch viel abgucken.  :Smile: 

----------

## UTgamer

 *Aldo wrote:*   

>  *UTgamer wrote:*   muß ich doch direkt mal nachschauen was -ftree-vectorize macht wenn openoffice sich auch damit sauber kompilieren läßt.  
> 
> Damit können automatisch SSE-Befehle des Prozessors genutzt werden um mehrere Daten mit einer Operation gleichzeitig zu verarbeiten.

 

Yeah, kommt direkt jetzt auch noch in meine CFlags-Sammlung nach make.conf  :Very Happy: 

----------

## Waiman

So, hab's jetzt auch geschaft, ohne -finline-functions.

Ich hab' 'nen Athlon64 3200+(2000Mhz) der auf 4025+ (2550Mhz) übertaktet ist und 2 GB Speicher.

Kann das, was genlop da behauptet überhaupt stimmen?? 

```

genlop -t openoffice

 * app-office/openoffice

     Mon Sep 24 14:41:08 2007 >>> app-office/openoffice-2.3.0

       merge time: 3 hours, 53 minutes and 17 seconds.

```

Ich bin erst heute Abend wiedergekommen und kann deshalb nicht sagen ob das stimmen kann.

Wie ermittelt genlop die Zeit? Hab den portage-tmp-Ordner auf einer noatime Partition. Vielleicht deshalb so ein Ergebnis. Was auf jeden Fall nicht stimmt ist die Startzeit: 14:41:08. gestartet hab' ich ca. 11:00 Uhr.

----------

## misterjack

 *Waiman wrote:*   

> 
> 
> ```
> 
> genlop -t openoffice
> ...

 

Was sagt, dass das die Startzeit ist? Und wieviel ist 14:41 minus 11:00 Uhr? Genau 3h und 41min, also kommt es auf die 3h und 53 Minuten hinaus. Und woher nimmst du deine Erkenntnis, dass die Zeit anhand des portage-tmp-Ordners gemessen wird? Sicherlich nicht, denn genlop nimmt dafür die Log-Datei /var/log/emerge.log

Und ja, es wird stimmen, ich brauch mit 3800+ nur ne Stunde länger  :Smile: 

----------

## Ampheus

Wie kommt ihr eigentlich auf 10.5 Stunden? Ich hab hier folgendes:

```
Mon Sep 24 20:49:46 2007 >>> app-office/openoffice-2.3.0

merge time: 3 hours, 55 minutes and 19 seconds.
```

Das ist auf meinem Laptop mit 1,5 GB RAM und Core Duo 1,83 Ghz.

----------

## Daimos

 :Rolling Eyes: 

ob der thread in vpenis ausartet?

 :Rolling Eyes: 

----------

## Waiman

 *Quote:*   

>  Was sagt, dass das die Startzeit ist? Und wieviel ist 14:41 minus 11:00 Uhr? Genau 3h und 41min, also kommt es auf die 3h und 53 Minuten hinaus. Und woher nimmst du deine Erkenntnis, dass die Zeit anhand des portage-tmp-Ordners gemessen wird? Sicherlich nicht, denn genlop nimmt dafür die Log-Datei /var/log/emerge.log

 

Klingt logisch die sache mit der Zeit. Wenn openoffice eh nur mit MAKEOPTS="-j1" kompiliert wird, würde das in der Relation zu einem Athlon64-X2 auch möglich sein.

Was das Zeit-messen angeht stellt sich dann die Frage ob die Zeit eben per "time" o.ä. ermittelt wird, oder aus irgendwelchen Datei-Timestamps errechnet. Auch die Zeit in /var/log/emerge.log ist ja irgendwie dort hereingekommen. Aber wenn's stimmt ist es eh egal.

Wie ich schon sagte, bin ich neu bei Gentoo und muss noch 'ne Menge Doku lesen. Geht eben nicht alles gleichzeitig.

Was mich aber verblüfft ist, dass hier gepostet wurde man könne openoffice auch mit -O3 kompilieren. Das würde ja -finline-functions mit einschließen. Und zumindest bei mir (und anderen auf Bugzilla) geht es dann definitiv nicht.

----------

## misterjack

 *Waiman wrote:*   

> Was das Zeit-messen angeht stellt sich dann die Frage ob die Zeit eben per "time" o.ä. ermittelt wird, oder aus irgendwelchen Datei-Timestamps errechnet. Auch die Zeit in /var/log/emerge.log ist ja irgendwie dort hereingekommen.

 

[ ] Du weißt wie Logging funktioniert. (das betrifft nicht nur Gentoo, sondern Linux allgemein)

Und zwar wie folgt am Beispiel von emerge.log:

- Ereignis A (Beginn von emerge paket) wird zum Zeitpunkt t1 protokolliert.

- Ereignis B (Beginn von emerge paket) wird zum Zeitpunkt t2 protokolliert.

Siehe:

```
1190655712: Started emerge on: Sep 24, 2007 19:41:52

1190655712:  *** emerge --oneshot =gnome-base/gconf-2.18.0.1

1190655713:  >>> emerge (1 of 1) gnome-base/gconf-2.18.0.1 to /

1190655713:  === (1 of 1) Cleaning (gnome-base/gconf-2.18.0.1::/usr/portage/gnome-base/gconf/gconf-2.18.0.1.ebuild)

1190655713:  === (1 of 1) Compiling/Merging (gnome-base/gconf-2.18.0.1::/usr/portage/gnome-base/gconf/gconf-2.18.0.1.ebuild)

1190655797:  >>> AUTOCLEAN: gnome-base/gconf

1190655797:  --- AUTOCLEAN: Nothing unmerged.

1190655797:  === (1 of 1) Post-Build Cleaning (gnome-base/gconf-2.18.0.1::/usr/portage/gnome-base/gconf/gconf-2.18.0.1.ebuild)

1190655797:  ::: completed emerge (1 of 1) gnome-base/gconf-2.18.0.1 to /

1190655797:  *** Finished. Cleaning up...

1190655798:  *** exiting successfully.

1190655798:  *** terminating.
```

Wie kommst du auf time oder Datei-Timestamps?

----------

## b3cks

 *Daimos wrote:*   

> 
> 
> ob der thread in vpenis ausartet?
> 
> 

 

Allein schon, weil fleißig mit sonderbaren CFlags rumgeschmissen wird, erkennt man, dass dies ein Ricer-Thread ist. Und Ricer-Threads sind ausschließlich auch vPenis-Threads. Das steht halt in Relation zueinander.  :Wink: 

----------

## Waiman

@misterjack: 

Warum stellst du mir eigentlich immer Gegenfragen? (<-Ist natürlich auch eine.)   :Very Happy: 

Ne knappe Antwort tut es ja manchmal auch. 

Abschließend, und ich meine damit auch abschließend, will eigentlich nur sagen, dass ich nicht vom Allgemeingültigen auf den Einzelfall schlussfolgere und ich einfach schreibe wie mir die Finger gewachsen sind. Da kann es auch mal vorkommen, dass ich mich nicht ausführlich genug äußere.

Danke für die Antworten auf meine Posts.

----------

## misterjack

 *Waiman wrote:*   

> 
> 
> Warum stellst du mir eigentlich immer Gegenfragen? (<-Ist natürlich auch eine.)  
> 
> Ne knappe Antwort tut es ja manchmal auch. 
> ...

 

Weil dein Ansatz, dass das Logging über Time und Datei-Timestamps geschieht schonmal grundlegend falsch ist. Deshalb darf man wohl nachfragen, wie du zu der falschen Erkenntnis gekommen bist?

----------

## AROK

 *musv wrote:*   

>  *AROK wrote:*   
> 
> Hätte ich auch mal stoppen sollen, aber länger als 8h hats bei mir nicht gedauert. 
> 
> ```
> ...

 

Halllo,

danke für den Tip!

So Sieht es bei mir aus, wirklich kürzer als 8h   :Laughing: 

```

splat openoffice

 * app-office/openoffice-2.2.1

        Emerged at: So Sep  2 00:33:30 2007

        Build time: 2 hours, 51 minutes, and 10 seconds

 * app-office/openoffice-2.3.0

        Emerged at: Do Sep 20 20:56:42 2007

        Build time: 3 hours, 18 minutes, and 51 seconds

```

Gruß

AROK

----------

## Max Steel

```
* app-office/openoffice

     Sat Aug 11 00:43:38 2007 >>> app-office/openoffice-2.2.1

       merge time: 10 hours, 59 minutes and 41 seconds.

     Mon Sep 24 09:50:56 2007 >>> app-office/openoffice-2.3.0

       merge time: 11 hours, 23 minutes and 59 seconds.
```

Naja ich habe hier 512MB RAM und eine AMD Athlon(tm) XP 1700+ mit den CFlags -march=athlon-xp -O2 -pipe

Als nichts neueres und schnelles.

----------

## hoschi

 *Ampheus wrote:*   

> So sieht es bei mir auch aus. Heißt das, bei der bin sind die Icons noch hässlicher oder besser gesagt "unpassender"?
> 
> Ich finde, obwohl ich MS nicht leiden kann, ist Office 2007 sehr gut geworden. Die Icons sind da viel übersichtlicher und das Programm ist um einiges besser zu bedienen. Da kann sich OOo noch viel abgucken. 

 

Gnome? branding flag an?

----------

## Ampheus

Gnome ist nciht meine Welt. Mein System ist komplett mit -gnome gebaut.

Ein branding-flag gibt es bei mir garnicht:

```
emerge -pv openoffice

These are the packages that would be merged, in order:

Calculating dependencies                   ... done!

[ebuild   R   ] app-office/openoffice-2.3.0  USE="cairo dbus firefox kde pam -binfilter -cups -debug -eds -gnome -gstreamer -gtk -java -ldap -mono -odk -seamonkey -sound -webdav -xulrunner" LINGUAS="de -af -ar -as_IN -be_BY -bg -bn -br -bs -ca -cs -cy -da -dz -el -en -en_GB -en_US -en_ZA -eo -es -et -fa -fi -fr -ga -gl -gu_IN -he -hi_IN -hr -hu -it -ja -km -ko -ku -lt -lv -mk -ml_IN -mr_IN -nb -ne -nl -nn -nr -ns -or_IN -pa_IN -pl -pt -pt_BR -ru -rw -sh_YU -sk -sl -sr_CS -ss -st -sv -sw_TZ -ta_IN -te_IN -tg -th -ti_ER -tn -tr -ts -uk -ur_IN -ve -vi -xh -zh_CN -zh_TW -zu" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB
```

----------

## s.hase

 *Ampheus wrote:*   

> 
> 
> Ein branding-flag gibt es bei mir garnicht:
> 
> 

 

Das scheint bei OO 2.3.0 weggefallen zu sein, dafür wird das Gentoo Branding jetzt automatisch gesetzt.

----------

## AROK

 *UTgamer wrote:*   

>  *Aldo wrote:*    *UTgamer wrote:*   muß ich doch direkt mal nachschauen was -ftree-vectorize macht wenn openoffice sich auch damit sauber kompilieren läßt.  
> 
> Damit können automatisch SSE-Befehle des Prozessors genutzt werden um mehrere Daten mit einer Operation gleichzeitig zu verarbeiten. 
> 
> Yeah, kommt direkt jetzt auch noch in meine CFlags-Sammlung nach make.conf 

 

Habs auch mal testweise mal probiert, bringt 1 Minute   :Confused:   Könnte also auch am Sonnenwind oder Luftdruck liegen   :Wink: 

----------

## Treborius

 *AROK wrote:*   

>  *UTgamer wrote:*    *Aldo wrote:*    *UTgamer wrote:*   muß ich doch direkt mal nachschauen was -ftree-vectorize macht wenn openoffice sich auch damit sauber kompilieren läßt.  
> 
> Damit können automatisch SSE-Befehle des Prozessors genutzt werden um mehrere Daten mit einer Operation gleichzeitig zu verarbeiten. 
> 
> Yeah, kommt direkt jetzt auch noch in meine CFlags-Sammlung nach make.conf  
> ...

 

was bringt eine minute?

weil cflags mit kompilierzeiten zu beurteilen, bringt ja wohl nur was, wenn man gcc vorher kompiliert ...

----------

## jm009

Bei mir gab es einen ähnlichen Fehler wie am Beginn des Threads (allerdings erst nach mindestens 5 Stunden Kompilierzeit  :Wink:  ):

------------------------------

Making: ../../../unxlngi6.pro/slo/download.obj

g++  -fmessage-length=0 -c -Os -fno-strict-aliasing   -I.  -I../../../unxlngi6.pro/inc/updchk -I../inc -I../../../inc/pch -I../../../inc -I../../../unx/inc -I../../../unxlngi6.pro/inc -I. -I/var/tmp/portage/app-office/openoffice-2.3.0/work/ooo/build/OOG680_m5/solver/680/unxlngi6.pro/inc/stl -I/var/tmp/portage/app-office/openoffice-2.3.0/work/ooo/build/OOG680_m5/solver/680/unxlngi6.pro/inc/external -I/var/tmp/portage/app-office/openoffice-2.3.0/work/ooo/build/OOG680_m5/solver/680/unxlngi6.pro/inc -I/var/tmp/portage/app-office/openoffice-2.3.0/work/ooo/build/OOG680_m5/solenv/unxlngi6/inc -I/var/tmp/portage/app-office/openoffice-2.3.0/work/ooo/build/OOG680_m5/solenv/inc -I/var/tmp/portage/app-office/openoffice-2.3.0/work/ooo/build/OOG680_m5/res -I/var/tmp/portage/app-office/openoffice-2.3.0/work/ooo/build/OOG680_m5/solver/680/unxlngi6.pro/inc/stl -I/var/tmp/portage/app-office/openoffice-2.3.0/work/ooo/build/OOG680_m5/solenv/inc/Xp31 -I/opt/blackdown-jdk-1.4.2.03/include -I/opt/blackdown-jdk-1.4.2.03/include/linux -I/opt/blackdown-jdk-1.4.2.03/include/native_threads/include -Idefault_x_includes     -I/var/tmp/portage/app-office/openoffice-2.3.0/work/ooo/build/OOG680_m5/solver/680/unxlngi6.pro/inc/offuh -I. -I../../../res -I. -pipe -O2 -mcpu=i686 -pipe -fvisibility-inlines-hidden -Wall -Wextra -Wendif-labels -Wshadow -Wno-ctor-dtor-privacy     -Wno-non-virtual-dtor   -fpic -DLINUX -DUNX -DVCL -DGCC -DC341 -DINTEL -DCVER=C341 -DNPTL -DGLIBC=2 -DX86 -D_PTHREADS -D_REENTRANT -DNEW_SOLAR -D_USE_NAMESPACE=1 -DSTLPORT_VERSION=400 -DHAVE_GCC_VISIBILITY_FEATURE -D__DMAKE -DUNIX -DCPPU_ENV=gcc3 -DGXX_INCLUDE_PATH=/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/include/g++-v4 -DSUPD=680 -DPRODUCT -DNDEBUG -DPRODUCT_FULL -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DGSTREAMER -DCUI -DSOLAR_JAVA -DOOG680=OOG680   -DSHAREDLIB -D_DLL_   -fexceptions -fno-enforce-eh-specs -DEXCEPTIONS_ON  -o ../../../unxlngi6.pro/slo/download.o /var/tmp/portage/app-office/openoffice-2.3.0/work/ooo/build/OOG680_m5/extensions/source/update/check/download.cxx

`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.

/var/tmp/portage/app-office/openoffice-2.3.0/work/ooo/build/OOG680_m5/extensions/source/update/check/download.cxx: In function 'bool curl_run(const rtl::OUString&, OutData&, const rtl::OString&, sal_Int32)':

/var/tmp/portage/app-office/openoffice-2.3.0/work/ooo/build/OOG680_m5/extensions/source/update/check/download.cxx:294: error: 'CURLOPT_RESUME_FROM_LARGE' was not declared in this scope

/var/tmp/portage/app-office/openoffice-2.3.0/work/ooo/build/OOG680_m5/extensions/source/update/check/download.cxx:314: error: 'curl_easy_strerror' was not declared in this scope

dmake:  Error code 1, while making '../../../unxlngi6.pro/slo/download.obj'

---* tg_merge.mk *---

ERROR: Error 65280 occurred while making /var/tmp/portage/app-office/openoffice-2.3.0/work/ooo/build/OOG680_m5/extensions/source/update/check

make: *** [stamp/build] Error 1

 *

 * ERROR: app-office/openoffice-2.3.0 failed.

 * Call stack:

 *   ebuild.sh, line 1654:   Called dyn_compile

 *   ebuild.sh, line 990:   Called qa_call 'src_compile'

 *   ebuild.sh, line 44:   Called src_compile

 *   openoffice-2.3.0.ebuild, line 338:   Called die

Nach einem Update von curl war aber alles ok:

emerge -v curl

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild     U ] net-misc/curl-7.16.4 [7.10.8-r1] USE="ipv6* kerberos%* ldap ssl -ares% -gnutls% -idn% -nss% -test%" 1,630 kB

Jetzt werd ich noch versuchen, bzgl. der Abhängigkeit von curl einen Bugreport zu erstellen.

----------

## UTgamer

Nur um das Bild abzurunden:

 *Treborius wrote:*   

>  *AROK wrote:*    *UTgamer wrote:*    *Aldo wrote:*    *UTgamer wrote:*   muß ich doch direkt mal nachschauen was -ftree-vectorize macht wenn openoffice sich auch damit sauber kompilieren läßt.  
> 
> Damit können automatisch SSE-Befehle des Prozessors genutzt werden um mehrere Daten mit einer Operation gleichzeitig zu verarbeiten. 
> 
> Yeah, kommt direkt jetzt auch noch in meine CFlags-Sammlung nach make.conf  
> ...

 

Ich habe gerade auf einem neu aufgesetzen Athlon 64 x2 OpenOffice 2.3.0 x86_64 installiert mit -ftree-vectorize und ohne -ffast-math. Der neue Rechner mit dem 3800+ X2 ist jetzt 2 Jahre jünger hat AM2-Chipsatz, DDR2-667MHz RAM und der Alte 3800- x2 nForce4-Chipsatz mit DDR2-400MHz RAM. 

Alle Konfigs des Neuen sind vom Alten übernommen.

Hier die Resultate:

Mit -ftree-vectorize und ohne -ffast-math brauchte Openoffice bei gcc-4.2.0 bei sonst gleichen USE-Flags auf dem Neuen: 

5 hours, 23 minutes and 36 seconds

Ohne -ftree-vectorize aber mit -ffast-math auf dem Alten mit gcc-4.1.2 und sonst gleichen USE-Flags:

5 hours, 15 minutes and 18 seconds

Ergebniss:

Ältere HW mit -ffast-math und älterem gcc und ohne -ftree-vectorize war 8 Minuten schneller.  :Very Happy: 

PS zum Vergleich: 

Die glibc-2.5-r4 war sogar wesentlich langsamer auf dem neuen:

Alte HW:  1 hour, 6 minutes and 34 seconds

Neue HW: 1 hour, 48 minutes and 41 seconds

Ergebniss:

Nichts geht über -ffast-math auf jeglichem Athlon  :Very Happy: 

(Auf Intel-Systemen ist von diesem Flag wegen Instabilitäten abzusehen.)

Das sollte nur der Vervollständigung der Diskussionen dienen.

----------

## misterjack

Ob nun ein so großes Paket 10 Minuten länger oder kürzer kompiliert ist doch egal. Hauptsache es läuft später stabil, was mit deinen Use-Flags laut Manpage nicht gegeben ist. Und dass du ja schon unerklärliche Software-Probleme hattest, ist ja nicht von der Hand zu weisen  :Smile: 

----------

## UTgamer

Diese USE-Flags die du als instabil bezeichnest sind es erstens nicht, laufen auf jeglichem Athlon höchst stabil, sowie sie auf meinem noch älteren Zweitrechner 32 Bit-Athlon XP 2400+ auf dem die MTAs installiert sind/waren garnicht aktiviert.sind, der ganz alte Zweitrechner von 2001 läuft komplett auf dem empfohlenem Standard, da dieser große Chipsatzfehler hat und nicht mal ACPI nutzen kann.  :Wink: 

----------

## s.hase

Jetzt mal ganz von dem unsicheren -ffast-math abgesehen hinkt der Vergleich aber trotzdem gewaltig. Es ist nun mal logisch das der Compiler für jede Optimierung auch länger braucht, Keine Ahnung wie man auf die Idee kommt das nen zusätzliches Flag beim compilieren selber Geschwindigkeit bringt. Dazu kommt dann noch der Vergleich von gcc-4.1.2 und 4.2.0. Das der 4.2er z.Z. bei identischen Flags noch etwas langsamer ist als der 4.1.2er ist nun mal bekannt. Wie es mit dem neuen 4.2.1 aussieht weiß ich nicht...

----------

## UTgamer

Ich weis das s.hase, deshalb habe ich auch direkt dazugeschrieben das die Kompiler nicht die gleiche Version haben. Aber da waren noch mehr Schreiber die teils Werte vom 4.2er abgegeben hatten. Diese haben damit auch gleich zusätzlich noch Vergleichswerte.

----------

## misterjack

 *UTgamer wrote:*   

> die du als instabil bezeichnest sind es erstens nicht, laufen auf jeglichem Athlon höchst stabil

 

Hast du dafür Beweise? Die Manpage sagt was anderes aus und zwar Prozessorunabhängig.

----------

## Polynomial-C

Wer -ffast-math nutzt, ist bei Problemen selber schuld. Glücklicherweise werden die meisten bugreports, in denen der Ersteller des bugs -ffast-math benutzt, als INVALID geschlossen...

----------

## UTgamer

 *misterjack wrote:*   

>  *UTgamer wrote:*   die du als instabil bezeichnest sind es erstens nicht, laufen auf jeglichem Athlon höchst stabil 
> 
> Hast du dafür Beweise? Die Manpage sagt was anderes aus und zwar Prozessorunabhängig.

 

a) Die Manpage ist sogar fehlerhaft in diesem Bereich.

b) Ja habe ich, les mal ab hier die Definitionen die ich aus verschiedenen original-verlinkten Dokumenten zusammen gesucht habe durch. Nirgendwo steht etwas von instabil für Athlons, nur für Intels:

https://forums.gentoo.org/viewtopic-p-4055750.html#4055750

 *Polynomial-C wrote:*   

> Wer -ffast-math nutzt, ist bei Problemen selber schuld. Glücklicherweise werden die meisten bugreports, in denen der Ersteller des bugs -ffast-math benutzt, als INVALID geschlossen...

 

Ja ist so, weil sie alle Intels Werbekampanien gegen ihren Hauptmitbewerber folgen.  :Sad: 

Les bitte den oben genannten Thread auch mal durch ohne die Intel-Vorurteile. Danach sagts du/ihr mir wo steht das es auf irgend einem Athlon instabil läuft.  :Very Happy: 

Nein nirgends ist es als instabil gebrandmarkt (Compilerprogrammierer wollen sich aber nicht festlegen das Float auch sauber laufen kann, nur ist diese Angabe bereits mit SSE1-4 das Float fast überall ersetzt längst überhohlt, yeah), und die Bearbeiter hinter bugs.gentoo.org kennen auch in dieser Hinsicht nur Intels Aussagen. Wenn ich mir so einige Pakete für AMD64 ansehe frage ich mich häufiger ob die Bearbeiter jemals einen AMD(64) benutzt noch jemals richtig ausgereizt haben ohne die üblichen Intelflags. Sie bauen die Pakete nicht anders als sie sie für den anderen Hersteller Intel bauen. 

Dabei haben die meisten überhaupt kaum Ahnung welches die Unterschiede zwischen AMD und Intel sind.

In diesem Thread habe ich dies ausreichend an Originaldokumenten veranschaulicht. Bis auf app-emulation/wine welches seine Optimierungen für MS-Windows macht gibt es eigentlich kein Paket welches auf einem Athlon nicht mit diesem CPU-Feature läuft.

Erklärt mir bitte auch mit Linkverweisen zu Entwicklerseiten (nicht Intel) warum mein System unstable sein soll, welches auch nach einer Woche Dauerbetrieb noch keinerlei Fehlfunktionen zeigt. Links zu GCC und anderen Kompilern sind im obigen Threadverweis bereits enthalten.  :Wink:  Ich warte gerne auf die Aussage das ihr mein System als unstable belegen könnt, wobei "man" an dieser Stelle selbst fehlerhaft ist.

Danke für die Mühe und Gruß,

ehemaliger m68k-Assemblerprogrammierer/Cracker (programmiert auf Maxon-ASM) und jetzt UTgamer.

--- ---

[Offtopic]

Ich habe hier mal einige Zusammenstellungen für m68k mit denen ich bereits FPU-Operationen vor mehr als 15 Jahren selbst programmiert habe, und dies im ganz normalen Softwarealltag:

 *Quote:*   

> Floating-point math refers to numeric calculations with a variable decimal point location. It
> 
> is distinguished from integer math, which deals only with whole numbers and fixed decimal
> 
> point locations. Historically, general-purpose microprocessors have had to depend on add-
> ...

 

Jetzt sagt mir bloß nicht das in den letzten 20 Jahren sich in FPU-Anweisungen alles verschlechtert hat. Nein hat es nicht, erst recht nicht bei AMD die viel gutes Know-How eingekauft haben (Next, Digital, IBM), siehe obigem Link. Das Intel da noch Probleme hat wundert mich garnicht nicht, siehe meine Signatur.  :Very Happy: 

Ich weiß worüber ich spreche wenn ich von FPU-Einbindungen spreche, wahrscheinlich besser als alle nicht Assemblerprogrammierer auch wenn ich ich dank Intel/Microsoft seit rund 12 Jahren nicht mehr programmiere.

----------

## Daimos

Da es in meiner Wohnung kalt ist und ich noch keine Heizung anmachen wollte, habe ich mal aus Jux selbige Compilerflags in mein Athlon64 System eingefügt, gleichzeitig ein "WANT_MP="true" in die make.conf gelegt. Unvernünftiger geht es kaum, ich weiss, aber das war mein Ziel.

Das System ist nicht produktiv, sondern mein PC zuhause mit existierendem Backup, außer Zeit war also nix zu verlieren.

Nach nem emerge --oneshot glibc binutils gcc folgte ein emerge -e system, gefolgt von einem emerge -e world (zwischen den letzten war ein Reboot, da ich zwischenzeitlich mal Win angemacht hatte, um ein bischen zu daddeln).

Das Resultat ist ein stabiles System, das bei keinem einzigen der Pakete ausgestiegen ist (ich habe das abgespeckte KDE laufen), Openoffice 2.3 ist auf 2 Kernen parallel in 3:05 durchgelaufen.

Klar möchte ich das nicht verallgemeinern, dass scharfe Compilerflags _immer_ problemlos laufen, wäre etwas ausgestiegen, hätte ich da auch erstmal die CFLAGS runtergefahren. Aber ich kann UTgamer da zustimmen, dass scharfe Compilerflags auch nicht automatisch zu Problemen führen. Derzeit ist die Kiste den 7. Tag oben und ich hatte noch keinerlei Unregelmäßigkeiten.

System: X2 3800+ @ 2x2400 MHz, 3 Gig Ram, 22er Gentoo-Sources auf ~amd64.

----------

## s.hase

 *Daimos wrote:*   

> 
> 
> Klar möchte ich das nicht verallgemeinern, dass scharfe Compilerflags _immer_ problemlos laufen, wäre etwas ausgestiegen, hätte ich da auch erstmal die CFLAGS runtergefahren. Aber ich kann UTgamer da zustimmen, dass scharfe Compilerflags auch nicht automatisch zu Problemen führen. Derzeit ist die Kiste den 7. Tag oben und ich hatte noch keinerlei Unregelmäßigkeiten.
> 
> 

 

Es hat auch keiner behauptet das es immer Probleme gibt, es kann aber. Das Problem dabei ist aber leider das ein erfolgreicher Compiler-Durchgang noch nicht heißt, dass das Programm auch wirklich fehlerfrei läuft. Ich hatte z.B. schon mal vor längerer Zeit -ffast-math bei mir gesetzt. Compilieren ließ sich damit alles ohne Probleme. Zu der Zeit habe noch Videodateien in DVD's umgewandelt. Auf einmal kam es beim Umwandeln zu unerklärlichen Programmabbrüchen oder das Ergebnis war einfach nur Schrott. Ich weiß jetzt auch nicht mehr welches Tool ich für das umwandeln genutzt habe, da das Script welches ich benutzt habe nicht von mir war. Wahrscheinlich war es transcode oder so, bin mir da jetzt aber nicht sicher. Daran sieht man das es ein Problem erst zur Laufzeit auftreten kann. Ohne -ffast-math ging wieder alles ohne Probleme und das auf einem AMD XP 2400! Kann natürlich das dieses Problem schon lange behoben ist.

Ich kann schon verstehen das die Gentoo Entwickler sagen das Flag ist gefährlich. Es kann halt nun Probleme bereiten und da einige User das dann gleich als Bug melden, ohne vorher zu testen ob es eventuell an ihren CFLAGS oder LDFLAGS lag, verschwendet es unnötig die wertvolle Zeit der Entwickler.

Es kann keiner verbieten das jemand z.B. -ffast-math als CFLAG setzt, ist ja auch i.O. so. Aber dann sollte man sich halt im Klaren sein das es Probleme geben kann und das man dann auch mal selber gucken muss ob es nun daran liegt bevor man nen Bug meldet. Gerade bei -ffast-math ist aber auch so, das die Pakete, die davon profitieren (bzw. die Entwickler meinen es würde davon profitieren), dieses CFLAG eigentlich automatisch setzen. Ich persönlich experimentiere ja auch gerne mit unterschiedlichen C- und LDFLAGS. Wenn aber irgendwas nicht mehr compiliert oder richtig läuft prüfe ich dann erstmal ob es an meinen Einstellungen liegt.

----------

## UTgamer

Mutig und danke Daimos für die Bestätigung meiner Aussagen. 

Jetzt sag mir bitte auch noch das WANT_MP="true" sauber mit allem durchgelaufen ist.  :Very Happy: 

[Edit]

 *s.hase wrote:*   

> Es hat auch keiner behauptet das es immer Probleme gibt, es kann aber. Das Problem dabei ist aber leider das ein erfolgreicher Compiler-Durchgang noch nicht heißt, dass das Programm auch wirklich fehlerfrei läuft.

 

Tun sie aber. 

Dabei erwähnst du ein Projekt zur Parallelisierung von Videodaten, nun auf experimentelle Programme kann man wirklich nicht vertrauen, und für diese habe ich auch garnicht geredet, wenn Code sehr unsauber ist kann man ihn auch nicht als Referenz heranziehen.

----------

## Daimos

 *Quote:*   

> Mutig und danke Daimos für die Bestätigung meiner Aussagen. 
> 
> Jetzt sag mir bitte auch noch das WANT_MP="true" sauber mit allem durchgelaufen ist.  
> 
> 

 

Exakt das ist der Fall. Auch Pakete wie kdelibs und eben OOo sind sauber auf beiden Kernen gegangen - sonst wär 3:05h auf nem So 939 System ja auch gar nicht machbar gewesen   :Smile: 

Und ja - es läuft stabil und ohne irgendwelche Zicken, es fault keine Segmentation in der Gegend rum, alles wie es soll.

----------

## s.hase

 *UTgamer wrote:*   

> 
> 
>  *s.hase wrote:*   Es hat auch keiner behauptet das es immer Probleme gibt, es kann aber. Das Problem dabei ist aber leider das ein erfolgreicher Compiler-Durchgang noch nicht heißt, dass das Programm auch wirklich fehlerfrei läuft. 
> 
> Tun sie aber. 

 

Mag sein es das bei Dir der Fall ist (und das streite ich ja gar nicht ab!), das muss aber nun mal nicht alle anderen möglichen Systemkonfigurationen gelten.

 *UTgamer wrote:*   

> Dabei erwähnst du ein Projekt zur Parallelisierung von Videodaten, nun auf experimentelle Programme kann man wirklich nicht vertrauen, und für diese habe ich auch garnicht geredet, wenn Code sehr unsauber ist kann man ihn auch nicht als Referenz heranziehen.

 

Ich weiss jetzt echt nicht was an transcode experimentell sein soll, wenn es nun überhaupt transcode war. Über die Codequalität kann und möchte ich mir auch kein Urteil erlauben.

----------

## UTgamer

 *Daimos wrote:*   

>  *Quote:*   Mutig und danke Daimos für die Bestätigung meiner Aussagen. 
> 
> Jetzt sag mir bitte auch noch das WANT_MP="true" sauber mit allem durchgelaufen ist.  
> 
>  
> ...

 

Du weisst das diese Aussage reicht meine 20 jährige Predigt das Intel *** gegenüber anderen Architekturen/Hersteller ist zu untermauern. *g* 

Das Portage-Flag ist direkt bei mir auch gesetzt, den soweit hatte ich die Entwicklung bei AMD noch nicht eingeschätzt, das schafft kein einziger Intel, weder mit -ffast-math noch mit WANT_MP="true".

Tut mir leid s.hase, wenn meine eigenen Untersuchungen das gleiche Ergebniss wie das von Daimos ergeben werden, glaube ich keiner einzigen Intelaussage mehr. Jegliche Warnung zeugt dann nur noch von Unwissenheit. Schau doch nur mal wieviele Fehler Intel über all die Jahre in ihren CPUs hatten (meine Signatur), während bei AMD keine größeren Hürden zu umschiffen waren. Falls du einen Intel hast dann versuche doch mal beide Anweisungen anzuwenden. Also bald werde ich es selbst ausprobiert haben und dann werden Daimos und ich sicher nicht mehr alleine sein. 

Danke allen Diskussionsbeteiligten, Openoffice diente leider wieder mal als das NonPlusUltra der Softwareentwicklung/Softwarekompilierung.

----------

## UTgamer

 *Daimos wrote:*   

>  *Quote:*   Mutig und danke Daimos für die Bestätigung meiner Aussagen. 
> 
> Jetzt sag mir bitte auch noch das WANT_MP="true" sauber mit allem durchgelaufen ist.  
> 
>  
> ...

 

So, nach 4 kompletten Neuinstallationen von vollwertigen Desktops auf AMD64 Athlons muß ich bestätigen das sowohl OpenOffice als auch alles andere fehlerfrei mit dem make.conf Eintrag WANT_MP="true" sowohl emerged als auch sauber funktioniert, 0 Fehler, und das selbst mit den CFLAGS die in meiner Signatur stehen.

CFLAGS="-march=athlon64 -O2 -msse3 -mfpmath=sse,387 -pipe -ffast-math -m64"

[Edit]

Überprüft mit GCC-4.1.2, GCC-4.2.0 und GCC-4.2.1   :Very Happy: 

OpenOffice mit GCC-4.2.1 = voll OK, nur KDE ein Problem.

----------

## Ampheus

OK, UTgamer ich hab hier mal ein anderes Beispiel von meinem Rechner. Es ist ein Intel Core Duo, folgendes sagt 'cat /proc/cpuinfo':

```
processor       : 0

vendor_id       : GenuineIntel

cpu family      : 6

model           : 14

model name      : Genuine Intel(R) CPU           T2400  @ 1.83GHz

stepping        : 8

cpu MHz         : 1833.000

cache size      : 2048 KB

physical id     : 0

siblings        : 2

core id         : 0

cpu cores       : 2

fdiv_bug        : no

hlt_bug         : no

f00f_bug        : no

coma_bug        : no

fpu             : yes

fpu_exception   : yes

cpuid level     : 10

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc pni monitor vmx est tm2 xtpr

bogomips        : 3662.32

clflush size    : 64

processor       : 1

vendor_id       : GenuineIntel

cpu family      : 6

model           : 14

model name      : Genuine Intel(R) CPU           T2400  @ 1.83GHz

stepping        : 8

cpu MHz         : 1833.000

cache size      : 2048 KB

physical id     : 0

siblings        : 2

core id         : 1

cpu cores       : 2

fdiv_bug        : no

hlt_bug         : no

f00f_bug        : no

coma_bug        : no

fpu             : yes

fpu_exception   : yes

cpuid level     : 10

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc pni monitor vmx est tm2 xtpr

bogomips        : 3657.87

clflush size    : 64
```

Soweit so gut. Nun aber mal die make.conf:

```
COREFLAGS="-frename-registers -fweb -pipe -fomit-frame-pointer -funit-at-a-time -freorder-blocks -fno-ident -freorder-blocks-and-partition -fmerge-all-constants -mno-tls-direct-seg-refs -ftree-vectorize"

CPUFLAGS="-msse3"

CFLAGS="-Os -mtune=prescott ${CPUFLAGS} ${COREFLAGS}"

CHOST="i686-pc-linux-gnu"

CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"

LDFLAGS="-Wl,-O1"

MAKEOPTS="-j3"

USE="X kde qt3 alsa cdr dvd win32codecs -gnome -gtk -arts -cups -ipv6 bzip2 nptl nptlonly kdehiddenvisibility -xmms mmx a52 aac -real dbus hal dvdread sse sse2 sse3 xvid acpi qt4 dvdr vcd cairo glitz mysql mssql -pcre unicode pdf asf mozbranding png svg aiglx -aalib flac mp3 vorbis bluetooth jpeg truetype opengl mpeg ogg mysqli apache2 php samba -kerberos -ldap automount bash-completion encode ffmpeg musepack sndfile mad cdparanoia dga speex xv xvmc -oss wifi branding firefox wmp divx xml german sdl -gpm -spell -berkdb -perl kdeenablefinal qt3support openal css tk smp emerald ctype pcre session unicode nognome rsvg irmc -evo ntfs dmx -real quicktime pic xcomposite -esd -gstreamer -eds lame xcb simplexml maps perl newspr nsplugin mjpeg lm_sensors gif dvdnav usb ipw3945 qt-copy"

FEATURES="candy parallel-fetch distlocks -metadata-transfer"

VIDEO_CARDS="vesa i810"

INPUT_DEVICES="mouse keyboard synaptics"

LINGUAS="de"

PORTDIR_OVERLAY="/usr/local/overlays/gentoo-xeffects /usr/local/overlays/kde4 /usr/local/overlays/personal"

GENTOO_MIRRORS="ftp://ftp.tu-clausthal.de/pub/linux/gentoo/ "

ALSA_CARDS="hda-intel"

PORTAGE_GPG_DIR="/var/tmp/portage"

PORTAGE_NICENESS="18"

WANT_MP="true"

CLEAN_DELAY="0"

CONFIG_PROTECT_MASK="/etc/init.d"
```

Auch hier ist WANT_MP="true" gesetzt und das System läuft seit ~6 Monaten so ohne Auffälligkeiten weder während des compilens, noch während der Laufzeit der Programme. Es sind auch noch viele andere flags gesetzt,die nicht als stable gelten. Auch OpenOffice-2.3 und sogar KDE4-svn wurden damit komplett ohne Probleme gebaut. OpenOffice wurde laut genlop in 3:55 Stunden gebaut. Bei mir funktioniert es, das heißt aber nicht, dass es bei Anderen auch so gut funktionieren muss. 

Ich denke also, dass auch Intel-CPUs mit WANT_MP="true" klar kommen können  :Smile: 

Sorry, nicht bös gemeint  :Smile: 

----------

## UTgamer

@Ampheus, nein habe ich schon richtig verstanden. Ich kann aber wenn ich solche Beiträge zu OpenOffice sehe und du der erste Intelbenutzer bist bei dem es (allerdings ausser -msse3 keine CoProzessoren ansprichst) nicht verstehen warum dies den nicht als Standard enabled ist. Entweder es läuft auf einer 100% Intelmachine sauber wie z.B. bei dir oder viele andere haben instabiele Systeme/HW. Oder wie erklärst du dir solche Beiträge?

 *dertobi123 wrote:*   

>  *Daimos wrote:*   Es sind aber auch beim 2.3er kaum Passagen, wo beide Kerne meines X2 belastet werden - unterm Strich holt der vielleicht 10 Minuten damit raus. 
> 
> OpenOffice ist da recht fragil, weshalb paralleles Build per default deaktiviert ist. Mit WANT_MP="true" emerge openoffice lässt sich ein paralleles Build aktivieren.

 

 *Daimos wrote:*   

> In der Tat - wenn ich es parallel erzwinge, geht es kaum reproduzierbar in die Binsen. 
> 
> Macht wohl doch Sinn, paralleles Backen einzuschränken 

 

 *TheCurse wrote:*   

> Scheinbar hat openoffice auch was gegen gcc-4.2.0, denn damit kompiliert es nicht, mit dem 4.1.2 schon.

 

PS, auch meine /proc/cpuinfo

```
processor       : 0

vendor_id       : AuthenticAMD

cpu family      : 15

model           : 35

model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 3800+

stepping        : 2

cpu MHz         : 2000.000

cache size      : 512 KB

physical id     : 0

siblings        : 2

core id         : 0

cpu cores       : 2

fpu             : yes

fpu_exception   : yes

cpuid level     : 1

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm cmp_legacy

bogomips        : 4019.71

TLB size        : 1024 4K pages

clflush size    : 64

cache_alignment : 64

address sizes   : 40 bits physical, 48 bits virtual

power management: ts fid vid ttp

processor       : 1

vendor_id       : AuthenticAMD

cpu family      : 15

model           : 35

model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 3800+

stepping        : 2

cpu MHz         : 2000.000

cache size      : 512 KB

physical id     : 0

siblings        : 2

core id         : 1

cpu cores       : 2

fpu             : yes

fpu_exception   : yes

cpuid level     : 1

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm cmp_legacy

bogomips        : 4017.97

TLB size        : 1024 4K pages

clflush size    : 64

cache_alignment : 64

address sizes   : 40 bits physical, 48 bits virtual

power management: ts fid vid ttp
```

Also es muß an irgend etwas liegen das es auch auf Intelprozessoren sauber laufen kann. Evtl. wurden ja wieder in neueren Kerneln erneut Microcodes (Bugbehebungen von Intel) eingespielt das es nun mit den neueren Kerneln bei denen auch standardmäßig geht, möglich ist dies, siehe Signatur.

Flagsvergleiche unseren funktionierenden Systmen:

```

Gemeinsame flags: 

fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush mmx fxsr sse sse2 ht nx pni 

Unterschiede in den flags, 

bei mir +: pse36 syscall mmxext fxsr_opt lm 3dnowext 3dnow lahf_lm cmp_legacy

bei dir +: dts acpi ss pbe tm constant_tsc monitor vmx est tm2 xtpr
```

Da es auch auf deinem System geht muß es also in den gleichen Flags stecken und nicht in den Unterschiedlichen.

Zitat Heise:

 *Quote:*   

> Bereits im April hatten große PC-Hersteller wie Dell, Fujitsu Siemens und Hewlett-Packard für viele ihrer Rechner mit Intel-Prozessoren BIOS-Updates mit neuen, "kritischen" Microcode-Updates bereitgestellt, Dell unter anderem für die Optiplex-745-Bürocomputer und HP beispielsweise für Server wie den ProLiant DL380 G5. Fujitsu Siemens erwähnt beim BIOS-Update R1.10 für den Esprimo P5915 ausdrücklich Microcode-Updates für Core-2-Duo-Prozessoren mit CPUID 0x6F9h, 0x6F2h oder 0x6F6h; in den Release Notes zur BIOS-Version R76 des Intel-Serverboards S5000VCL schreibt Intel: "Add microcode updates M046F6C6 and M406F766 to eliminate a potential source of unpredictable system behavior". Im aktuellen Core 2 Duo Specification Update in Revision 14 sind mehrere "Errata" erwähnt, die sich mit BIOS-Patches umgehen lassen sollen.

 

Evtl. hat dein Mainboardhersteller bereits vor den 6 Monaten aktualisierte Microcodes eingespielt gehabt, oder du ein BIOS-Update selbständig gemacht, vor welchem viele berechtigterweise zurückscheuen.

Da Intel-Microcodes auch in die Kernel eingepflegt werden, sollte emerge bei der Kompilation für das WANT_MP="true" für 100% Intelprozessoren doch am besten die Kernelversion abfragen, und dann kann das Portageflag einfach für alle auf Dauer eingeschaltet werden.   :Very Happy:  << Für mehr Kompilationskomfort, wer wartet den gerne fast die doppelte Zeit, wenn es anders auch fehlerfrei geht.

----------

