# dev-lang/python compilierfehler

## Yonathan

guten morgen.

beim neubau meines test-systems bleibe ich immer an dieser stelle hängen:

```
Compiling /var/tmp/portage/python-2.4.4/image//usr/lib/python2.4/xmlrpclib.py ...

Compiling /var/tmp/portage/python-2.4.4/image//usr/lib/python2.4/zipfile.py ...

make: *** [libinstall] Fehler 1

!!! ERROR: dev-lang/python-2.4.4 failed.

Call stack:

  ebuild.sh, line 1539:   Called dyn_install

  ebuild.sh, line 1013:   Called src_install

  python-2.4.4.ebuild, line 188:   Called die

!!! (no error message)

!!! If you need support, post the topmost build error, and the call stack if relevant.
```

```
dev-lang/python-2.4.4 [2.4.3-r1] USE="berkdb* gdbm* ipv6* ncurses* readline* ssl* -build* -tk%
```

 sind die useflags dazu

in der make.conf steht:

```
CFLAGS="-O3 -march=athlon-xp -msse -mmmx -m3dnow -fomit-frame-pointer -fforce-addr -ftracer -pipe -falign-functions=4 -fprefetch-loop-arr$

CHOST="i686-pc-linux-gnu"

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

MAKEOPTS="-j2"

GENTOO_MIRRORS="http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo

http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo"

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

ACCEPT_KEYWORDS="~x86"

PORTAGE_NICENESS=3

AUTOCLEAN="yes"

FEATURES="distlocks sandbox userpriv usersandbox"

USE="nptl nptlonly -fortran -X -tk"
```

wie gesagt, das ganze ist ein testsystem und wird nach dieser anleitung gebaut. bin grade im letzten teil von schritt 9 und versuchte:

```
emerge -e --oneshot linux-headers man-pages glibc binutils gcc coreutils zlib findutils mktemp gawk ncurses sys-libs/readline vim nano m4 bison less groff sed flex gettext perl sys-apps/texinfo autoconf automake bash file libtool bzip2 diffutils kbd reiserfsprogs grep gzip hotplug man make module-init-tools patch procps psmisc shadow sysklogd sysvinit tar udev util-linux
```

hat da jemand eine idee, warum dieser fehler auftritt und wie man ihn beseitigt? habe emerge mehrmal laufen lassen, aber es hängt immer an der stelle

yona

----------

## Knieper

 *Yonathan wrote:*   

> 
> 
> in der make.conf steht:
> 
> ```
> ...

 

Ich nehme mal an, das $-Zeichen ist ein Kopierfehler. Meinst Du nicht, die CFLAGS sind ein wenig uebertrieben, um sich dann ueber build-Fehler zu wundern?

 *Quote:*   

> wie gesagt, das ganze ist ein testsystem und wird nach dieser anleitung gebaut. bin grade im letzten teil von schritt 9 und versuchte

 

Wieso sollte man dieser Anleitung auch nur teilweise folgen wollen? Die ist total laecherlich.

----------

## Klaus Meier

Steht hier irgendwo in der Doku oder den GWN. Fehlermeldungen werden nur dann akzeptiert, wenn man nicht mehr als -O2 und -fomit-framepointer verwendet.

----------

## Yonathan

ob lächerlich oder nicht, ich find es nicht schlecht und es scheint zu funktionieren, sonst gäbe es nicht so viele zusprüche dafür im thread.

die CFLAGS funktionieren eigentlich ganz wunderbar, da sie an mein system angepasst sind. warum sollte ich nicht einbauen, was mein prozessor und meine arch unterstützen? gcc hat da eine tolle homepage, wo sowas steht und auf meinem jetzigen system habe ich da auch keine probleme mit gehabt bislang.

und ja, das $ ist ein kopierfehler, weil die zeile über den bildschirm rausging.

werde das ganze mal mit -O2 und -fomit-frame-pointer probieren und dann hier berichten

----------

## Klaus Meier

Also so Worte wie "scheint" und "eigentlich" finde ich in diesem Zusammenhang dann doch etwas nicht so ganz überzeugend. Das ganze mmx und sse Geraffel sollte durch die Angabe von march erschlagen werden. Und zum Rest, berichte doch einfach mal, was für einen Unterschied du feststellst.

----------

## schachti

 *Yonathan wrote:*   

> ob lächerlich oder nicht, ich find es nicht schlecht und es scheint zu funktionieren, sonst gäbe es nicht so viele zusprüche dafür im thread.
> 
> 

 

Wenn es funktionieren würde, würdest Du hier nicht um Hilfe fragen.   :Twisted Evil: 

Geht's denn mit dem Kompilieren, wenn Du dafür mal auf sichere CFLAGS umstellst?

----------

## Carlo

 *Klaus Meier wrote:*   

> Fehlermeldungen werden nur dann akzeptiert, wenn man nicht mehr als -O2 und -fomit-framepointer verwendet.

 

Ganz so ist das nicht, zumal -fomit-framepointer bei x86 zu nicht verwertbaren Backtraces führt. Aber um das Beispiel mal auseinanderzunehmen:

 *Knieper wrote:*   

> 
> 
> ```
> CFLAGS="-O3 -march=athlon-xp -msse -mmmx -m3dnow -fomit-frame-pointer -fforce-addr -ftracer -pipe -falign-functions=4 -fprefetch-loop-arr$
> 
> ...

 

Ganz bestimmt hast du dich nicht schlau gemacht, was du da eigentlich tust:

-march=athlon-xp impliziert -msse -mmmx -m3dnow

-O3 impliziert -falign-functions=4 und -fprefetch-loop-arrays

Bleibt also -O3 -march=athlon-xp -fomit-frame-pointer -fforce-addr -ftracer -pipe. Von -ftracer würde ich abraten, das macht zu häufig Probleme. Und -O2 ist sicherlich sinnvoller bei der CPU, als -O3.

Mit der Build-Fehlermeldung läßt sich leider nicht viel anfangen.

----------

## schachti

 *Carlo wrote:*   

> 
> 
> -march=athlon-xp impliziert -msse -mmmx -m3dnow
> 
> 

 

Das geht zumindest aus der man page zu gcc nicht hervor.

 *Carlo wrote:*   

> 
> 
> -O3 impliziert -falign-functions=4 und -fprefetch-loop-arrays
> 
> 

 

Laut man page wird -falign-functions (ohne Angabe von =n) von -O2 aktiviert, und über -fprefetch-loop-arrays wird lediglich gesagt, daß es von -=s deaktiviert wird.

Gibt es eine Doku, aus der in dieser Hinsicht mehr hervorgeht als aus der man page?

----------

## Carlo

 *schachti wrote:*   

> Laut man page wird -falign-functions (ohne Angabe von =n) von -O2 aktiviert, und über -fprefetch-loop-arrays wird lediglich gesagt, daß es von -=s deaktiviert wird.
> 
> Gibt es eine Doku, aus der in dieser Hinsicht mehr hervorgeht als aus der man page?

 

Du kannst in den Quellcode gucken. Die man page ist aber eigentlich hinreichend. -O3 aktiviert alles, was -O2 aktiviert. "n" wird von der Wortbreite der CPU abhängig gesetzt. Was -fprefetch-loop-arrays angeht, war ich ehrlich gesagt davon ausgegangen, daß es es mit -O3 aktiviert wird. Aber dies ist in der Tat nicht der Fall. Ich würde in dem Fall einfach mal auf die Kompetenz der GCC-Entwickler bauen und es nicht verwenden. Viel hilft viel gilt bei Compiler Flags einfach nicht. Die Kombination von -finline-functions (impliziert durch -O3) und -fforce-addr ist übrigens auch für Überraschungen gut.

----------

## Klaus Meier

Wenn man beim Kompilieren mal auf den Bildschirm schaut, dann sieht man, dass viele ebuilds inzwischen spezielle Compiler- und Linkerflags setzen. Das ist auch das einzige, was Sinn ergibt. Weil dann getestet werden kann, dass diese Option mit dieser Anwendung keine Probleme macht und auch spezifische Vorteile bringt. Man kann sich über -O2 oder -Os Gedanken machen, alles andere bringt in der make.conf gar nichts. Was nutzt es mir, wenn der Firefox 10 Sekunden länger zum starten braucht, damit er dann eine Seite 1% schneller darstellt.

----------

## schachti

Ich kann mir vorstellen, daß bestimmte Flags schon Sinn machen, wenn sie bei bestimmten Anwendungen gesetzt werden. Die Frage ist, inwiefern daß bereits bei allen Paketen, die wirklich davon profitieren, passiert.

Gerade -mmmx -m3dnow -msse3 -mfpmath=sse haben doch bei Multimedia-Anwendungen und bei rechenintensiven Programmen unter Umständen ihre Berechtigung... Und im Gegensatz zu -ffast-math sind sie, soweit ich es beurteilen kann, nicht unbedingt dafür berüchtigt, kaputten Binärcode zu produzieren.

----------

## Klaus Meier

 *schachti wrote:*   

> Gerade -mmmx -m3dnow -msse3 -mfpmath=sse haben doch bei Multimedia-Anwendungen und bei rechenintensiven Programmen unter Umständen ihre Berechtigung... Und im Gegensatz zu -ffast-math sind sie, soweit ich es beurteilen kann, nicht unbedingt dafür berüchtigt, kaputten Binärcode zu produzieren.

 

march=athlon-xp setzt die von dir angegebenen -mxxx. Hat Carlo doch schon oben geschrieben.

----------

## schachti

ok, das mag bei -march=athlon-xp so sein, ich weiß nicht, wie es bei anderen Architekturen und mit anderen Flags (zum Beispiel -mfpmath=sse) ist. Ich wollte auch nicht irgendwelche extremen Flags verteidigen - ich wollte nur sagen, daß es manchmal Sinn machen könnte, etwas zu setzen, das über -O2 hinausgeht. Und: Nein, ich bin kein Ricer.   :Wink: 

----------

## Klaus Meier

 *schachti wrote:*   

> ok, das mag bei -march=athlon-xp so sein, ich weiß nicht, wie es bei anderen Architekturen und mit anderen Flags (zum Beispiel -mfpmath=sse) ist. Ich wollte auch nicht irgendwelche extremen Flags verteidigen - ich wollte nur sagen, daß es manchmal Sinn machen könnte, etwas zu setzen, das über -O2 hinausgeht. Und: Nein, ich bin kein Ricer.  

 

Ist schon klar. -mfpmath=irgendwas hat bei mir in Benschmarks den Code nur verschlechtert. Das macht der Compiler wohl inzwischen alleine intelligenter. Ansonsten ist http://gentoo-wiki.com/CFLAGS_matrix mal ganz nett, obwohl es wohl nicht mehr sonderlich aktuell ist und einiges schon überholt ist.

----------

