hi leute ich ahabe folgendes problem: ich habe einen athlon 700 MHz zu hause und einen pentium III mit 600 MHz an meinem arbeits platz. beide mit suse 7.1. mein problem ist, wenn ich ein srpm compilieren will, dann kann ich auf dem pentium III rechner das --target=athlon angeben. alles klappt wunderbar, aber zu hause wo ich ein athlon hätte, bricht der befahel rpm -ba --target=athlon SPEC/foo.spec mit einer fehler meldung ab. der fehler ist nicht immer der selbe, aber er hat immer was mit der architektur zu tun. zum beispiel: ... autoconf CFLAGS="-O2 -march=athlon -funroll-loops -pipe -D_GNU_SOURCE -D_SVID_ SOURCE -Wall" LDFLAGS=-s LIBS=-lc sh configure --prefix=/usr --enable -dups \ --enable-setuid=man --with-device=latin1 \ --mandir=/usr/share/man creating cache ./config.cache checking for gcc... gcc checking whether the C compiler (gcc -O2 -march=athlon -funroll-loops -pipe -D_GNU_SOURCE -D_SVID_SOURCE -Wall -s) works... no configure: error: installation or configuration problem: C compiler c annot create executables. make: *** [GNUmakefile] Error 1 Bad exit status from /var/tmp/rpm-tmp.20673 (%build) trinity:/usr/src/packages # wieso klappt das auf meinem athlon system nicht? gruss benjamin
Benjamin Hofstetter wrote:
hi leute
ich ahabe folgendes problem: ich habe einen athlon 700 MHz zu hause und einen pentium III mit 600 MHz an meinem arbeits platz. beide mit suse 7.1.
mein problem ist, wenn ich ein srpm compilieren will, dann kann ich auf dem pentium III rechner das --target=athlon angeben. alles klappt wunderbar, aber zu hause wo ich ein athlon hätte, bricht der befahel rpm -ba --target=athlon SPEC/foo.spec mit einer fehler meldung ab. der fehler ist nicht immer der selbe, aber er hat immer was mit der architektur zu tun.
zum beispiel:
... autoconf CFLAGS="-O2 -march=athlon -funroll-loops -pipe -D_GNU_SOURCE -D_SVID_ SOURCE -Wall" LDFLAGS=-s LIBS=-lc sh configure --prefix=/usr --enable -dups \ --enable-setuid=man --with-device=latin1 \ --mandir=/usr/share/man creating cache ./config.cache checking for gcc... gcc checking whether the C compiler (gcc -O2 -march=athlon -funroll-loops -pipe -D_GNU_SOURCE -D_SVID_SOURCE -Wall -s) works... no configure: error: installation or configuration problem: C compiler c annot create executables. make: *** [GNUmakefile] Error 1 Bad exit status from /var/tmp/rpm-tmp.20673 (%build) trinity:/usr/src/packages #
wieso klappt das auf meinem athlon system nicht?
In Deinem Beispiel überschreibst Du einige vom configure-Script und von den Makefiles zu verarbeitende Flags (CFLAGS, LDFLAGS, LIBS). Was in diesen Flags stehen darf ist keinesfalls frei wählbar, sondern von einer ganzen Reihe von Faktoren abhängig, d.h. man muss genau wissen, welche Flags man setzen darf und welche nicht. Welche das im Einzelfall sind, hängt von einer Vielzahl von Faktoren ab und lässt sich nicht Allgemein beantworten. In Deinem speziellen Beispiel würde der Inhalt von config.log weiterhelfen, so aber bleibt die Glaskugel :) Ganz allgemein gesprochen, sieht Dein Beispiel sehr verdächtig aus: * CFLAGS=-pipe -D_GNU_SOURCE -D_SVID sollte man nur dann setzen, wenn man weiss was man tut. * CFLAGS=-O2 und -march, sowie LDFLAGS=-s sind in vielen Fällen harmlos, es gibt aber Ausnahmen (Ich perönlich halte LDFLAGS=-s für einen Fehler, man kann aber geteilter Meinung darüber sein). * LIBS=-lc ist, zurückhaltend formuliert, ein eindeutiges Indiz für fehlerhafte und/oder schlechte Makefiles, da es eigentlich _niemals_ notwendig ist -lc explizit anzugeben. Ansonsten wäre anzumerken, dass * -march=athlon nicht von allen gcc-Versionen unterstützt wird. Es könnte also sein, dass auf beiden Maschinen verschiedene Versionen des gcc installiert sind. * der gleiche Fehler auftritt, wenn Teile des gcc oder der libc fehlen. * u.U. verschiedene Versionen von RPM installiert seien könnten, die unterschiedliche RPM-FLAGS setzen, falls diese FLAGS aus RPM stammen sollen. Ralf
On Mon, 04 Jun 2001, Ralf Corsepius wrote:
* CFLAGS=-O2 und -march, sowie LDFLAGS=-s sind in vielen Fällen harmlos
Ack.
Ansonsten wäre anzumerken, dass * -march=athlon nicht von allen gcc-Versionen unterstützt wird. Es könnte also sein, dass auf beiden Maschinen verschiedene Versionen des gcc installiert sind.
Ziemlich eindeutig sogar. Das Flag -march=athlon (oder -mcpu=) wird AFAIK nur vom Athlon-Patch zum Pentium-Patch >= 2.95.3 des gcc 2.95.2 (und evtl. neuere) unterstuetzt. Evtl. ist das beim inoffiziellen gcc 2.96 aber anders. Ich habe hier den Athlon-Patch in obigen Versionen: gcc version pgcc-2.95.3 19991024 (AMD-20000925-1) und verwende meist "-march=i686 -mcpu=athlon". Generell kann ich auf dem Athlon wohl folgende Flags empfehlen: -Wall -O2 -march=i686 -mcpu=athlon -malign-functions=4 -fschedule-insns2 \ -mwide-multiply In letzter Zeit immer oefter durch ein "-W -Wno-unused" ergaenzt ;) Diese Flags (und nur diese) sollten in fast allen Faellen passen, AFAIK auch generell (eben ohne die =athlon Flags eben), da sie _nur_ die Features der Athlon Architektur ansprechen. Siehe auch wie in /usr/src/linux/arch/i386/Makefile die Prozessor- spezifischen Flags gesetzt werden, z.B.: ifdef CONFIG_MK7 CFLAGS += [..] endif -dnh -- 48: Nutzt die neuen Möglichkeiten von Windows'95! Haben Sie unser anderes Update schon gekauft? (Kristian Köhntopp)
* David Haller schrieb am 04.06.01 um 09:56 Uhr:
On Mon, 04 Jun 2001, Ralf Corsepius wrote:
* CFLAGS=-O2 und -march, sowie LDFLAGS=-s sind in vielen Fällen harmlos
Ack.
Ansonsten wäre anzumerken, dass * -march=athlon nicht von allen gcc-Versionen unterstützt wird. Es könnte also sein, dass auf beiden Maschinen verschiedene Versionen des gcc installiert sind.
Ziemlich eindeutig sogar. Das Flag -march=athlon (oder -mcpu=) wird AFAIK nur vom Athlon-Patch zum Pentium-Patch >= 2.95.3 des gcc 2.95.2 (und evtl. neuere) unterstuetzt. Evtl. ist das beim inoffiziellen gcc 2.96 aber anders. Ich habe hier den Athlon-Patch in obigen Versionen:
gcc version pgcc-2.95.3 19991024 (AMD-20000925-1)
Hi David, Hast du irgendwelche Vergleiche zwischen "normal" compilierten binaries und den Athlon-Optimierten? Lohnt sich der Aufwand, sich einen neuen Compiler zu basteln? Wenn ja, hast du nicht zufaellig ein RPM vom pgcc mit Athlon-Patch? ;-) Gruss -Marc -- +------------------------------------------------------------------+ | --> http://www.links2linux.de <-- Jetzt mit neuen Features! | | wie z.B. [EasyLink] | +---Registered-Linux-User-#136487------------http://counter.li.org +
On Mon, 04 Jun 2001, Marc Schiffbauer wrote:
* David Haller schrieb am 04.06.01 um 09:56 Uhr:
Ziemlich eindeutig sogar. Das Flag -march=athlon (oder -mcpu=) wird AFAIK nur vom Athlon-Patch zum Pentium-Patch >= 2.95.3 des gcc 2.95.2
Hast du irgendwelche Vergleiche zwischen "normal" compilierten binaries und den Athlon-Optimierten? Lohnt sich der Aufwand, sich einen neuen Compiler zu basteln?
Nicht wirklich. Ich hab mit bzip2 (0.95.2) ein wenig rumgestestet, gebracht hat v.a. das -march=i686 und die anderen -m Flags. IIRC hat der pgcc dann noch einen Tick gebracht, der Athlon-patch praktisch nix.
Wenn ja, hast du nicht zufaellig ein RPM vom pgcc mit Athlon-Patch? ;-)
Nein. -dnh -- Ich weise allerdings jede Verantwortlichkeit von mir. Wer mich siggt, ist selber schuld und hat die Konsequenzen zu tragen. Du bist gewarnt. [Moss in suse-talk]
* David Haller schrieb am 04.06.01 um 19:29 Uhr:
On Mon, 04 Jun 2001, Marc Schiffbauer wrote:
* David Haller schrieb am 04.06.01 um 09:56 Uhr:
Ziemlich eindeutig sogar. Das Flag -march=athlon (oder -mcpu=) wird AFAIK nur vom Athlon-Patch zum Pentium-Patch >= 2.95.3 des gcc 2.95.2
Hast du irgendwelche Vergleiche zwischen "normal" compilierten binaries und den Athlon-Optimierten? Lohnt sich der Aufwand, sich einen neuen Compiler zu basteln?
Nicht wirklich. Ich hab mit bzip2 (0.95.2) ein wenig rumgestestet, gebracht hat v.a. das -march=i686 und die anderen -m Flags.
Aha. Schonmal gut zu wissen. Hast du ne Hausnummer, vielleicht Pi*Daumen in Prozent, wieviel das ausmacht? Denn wenn man es *wirklich* merkt, wuerde ich mir auch vielleicht mal die KDE und X-Pakete als i686-Pakete uebersetzen wollen. Gruss -Marc -- +-O . . . o . . . O . . . o . . . O . . . ___ . . . O . . . o .-+ | Ein neuer Service von Links2Linux.de: / o\ RPMs for SuSE | | --> PackMan! <-- naeheres unter | __| and others | | http://packman.links2linux.de/ . . . O \__\ . . . O . . . O . |
On Tuesday 05 June 2001 10:59, Marc Schiffbauer schrieb:
* David Haller schrieb am 04.06.01 um 19:29 Uhr:
On Mon, 04 Jun 2001, Marc Schiffbauer wrote:
* David Haller schrieb am 04.06.01 um 09:56 Uhr:
Ziemlich eindeutig sogar. Das Flag -march=athlon (oder -mcpu=) wird AFAIK nur vom Athlon-Patch zum Pentium-Patch >= 2.95.3 des gcc 2.95.2
Hast du irgendwelche Vergleiche zwischen "normal" compilierten binaries und den Athlon-Optimierten? Lohnt sich der Aufwand, sich einen neuen Compiler zu basteln?
Nicht wirklich. Ich hab mit bzip2 (0.95.2) ein wenig rumgestestet, gebracht hat v.a. das -march=i686 und die anderen -m Flags.
Aha. Schonmal gut zu wissen. Hast du ne Hausnummer, vielleicht Pi*Daumen in Prozent, wieviel das ausmacht?
Ich habe früher mal mit dem PGCC von Marc Lehmann et al. etliches neukompiliert für meinen Pentium 166 damals. bzip2 hat fast 30% gebracht, andere Apps nicht soviel. Später hab ich gleiches mit dem K6-II probiert: Fast kein Effekt. Ebensowenig mit dem Cyrix P6.
Denn wenn man es *wirklich* merkt, wuerde ich mir auch vielleicht mal die KDE und X-Pakete als i686-Pakete uebersetzen wollen.
Afaik sind die "neueren" (Nach Pentium-I) Prozessoren nicht mehr so empfindlich auf "schlecht optimierten" Code. Die haben eine gute Sprungvorhersage usw. Da hilft Schleifen auspacken auch nicht mehr viel. Ausserdem benutzen die Standard-apps genausowenig 3dnow!, mmx, oder sse(2), so dass sich ein neukompilieren in den meisten Fällen nicht lohnt. -- Mathias Weigt
On Die, 05 Jun 2001, Mathias Weigt wrote:
On Tuesday 05 June 2001 10:59, Marc Schiffbauer schrieb:
Aha. Schonmal gut zu wissen. Hast du ne Hausnummer, vielleicht Pi*Daumen in Prozent, wieviel das ausmacht?
Ich habe früher mal mit dem PGCC von Marc Lehmann et al. etliches neukompiliert für meinen Pentium 166 damals. bzip2 hat fast 30% gebracht, andere Apps nicht soviel.
Kommt hin. Der Athlon-patch zum pgcc hat dann IIRC nochmal 1-3% gebracht. -dnh -- Es gibt schließlich auch weitgehend DAU-sichere Programme, das Problem ist allerdings, daß bereits die Programmierer von OE die größten DAUs sind. Da helfen keine Pillen. :-( -- Doch, eine häts gegeben, nur hätte man /Frau die etwa 9 Monate vor der Geburt der Programmierer einnehmen müssen... [in dag°]
participants (5)
-
Benjamin Hofstetter -
David Haller -
Marc Schiffbauer -
Mathias Weigt -
Ralf Corsepius