prozessor-optimierte compilation
Andre Homberg
ich habe probleme mit der prozessor-optimierten compilation. ich setzte
suse-73 mit dem standard-c-compilier gcc-v2.95.3 ein.
ich habe mplayer-v0.60 einmal mit der option "./configure
--host=i386-pc-linux-gnu" compiliert und einmal mit "./configure
--host=i686-pc-linux-gnu" und erhalte jeweils _genau_ die gleiche
datei-groesse. waherend des compilierens werden bei beiden varianten
jeweils die flags "-O4 -march=i486 -mcpu=i686" verwendet.
daraufhin habe ich mplayer mit './configure --host=i386-pc-linux-gnu' und
'make OPTFLAGS="-O3 -mcpu=i386 -march=i386"' compiliert. und ich hatte eine
andere dateigroesse. als ich './configure --host=i386-pc-linux-gnu' und
'make OPTFLAGS="-O3 -mcpu=i386 -march=i386"'verwendetet, aenderte sich die
dateigroesse ebenfalls.
mit "file /usr/local/bin/mplayer" erhalte ich dagegen _jeweils_ "ELF 32-bit
LSB executable, Intel 80386, version 1, dynamically linked (uses shared
libs), stripped"
warum scheint "--host=" nicht beachtet zu werden? - was genau sollte
"--host" im Makefile veraendern?
wofuer steht genau "march", wofuer steht genau "mcpu"?
wo unterscheiden sich "--host" und "--target"?
und wenn march/mcpu fuer die prozessor-optimierung zustaendig sind, wie kann
ich diese am besten setzten. ein 'make CFLAGS="-mcpu=i386 -march=i386"'
wuerde in den meisten faellen irgentwelche flags (zb -Wall) aus dem
Makeflile ueberschreiben. zu guter letzt noch folgende frage: was ist wenn
"gcc -O1 -mcpu=i486 -Wall -O3 -mcpu=i686 test.c -o test" erscheint? welche
flags wuerde der compiler verwenden?
1000 fragen - aber ich finde keine sicheren aussagen...
gruss,
andre
Walter Mühlheim
> ich habe probleme mit der prozessor-optimierten compilation. ich setzte
> suse-73 mit dem standard-c-compilier gcc-v2.95.3 ein.
Guck Dir mal die Dateien /usr/share/info/gcc.* an.
Dir fehlen elementare Grundkenntnisse bei der Verwendung des Compilers und
des Befehls file.
Für den Anfang versuche es mit
man gcc
man file
Wenn Du kde benutzt, kannst Du die obigen Info-Seiten mit <alt>-<f2>
bekommen. In die Eingabezeile einfach "info:/gcc" eingeben.
An gleicher Stelle kannst Du auch man file und man gcc eingeben.
export CFLAGS="-mcpu=i386" ; make
Die Optionen CFLAGS ist für eigenen Optimierungsschalter gedacht. Allerdings
halten sich nicht alle Programmierer daran.
Ansonsten macht gerade dieser Flag keinen Sinn, Dein compilier diesen
Schalter wahrscheinlich als Default benutzt.
Mfg
Martin Dickopp
> mit "file /usr/local/bin/mplayer" erhalte ich dagegen _jeweils_ "ELF 32-bit
> LSB executable, Intel 80386, version 1, dynamically linked (uses shared
> libs), stripped"
Was stört Dich denn daran, das "Intel 80386"? Das bedeutet lediglich,
daß es sich um ein Executable für x86-kompatible Prozessoren (im Gegen-
satz z.B. zu Sparc-Prozessoren) handelt.
Optimierung für unterschiedliche Prozessormodelle bewirkt, daß
Maschineninstruktionen in unterschiedlicher Reihenfolge angeordnet
werden, und ähnliches. Es dürfte also schwierig sein, dem fertigen
Executable anzusehen, für welches Prozessormodell es optimiert wurde.
> warum scheint "--host=" nicht beachtet zu werden? - was genau sollte
> "--host" im Makefile veraendern?
Der Programmautor kann den Wert von --host im configure-Skript
abfragen. Was er mit dieser Information macht, bleibt ihm überlassen.
Die meisten Projekte verwenden sie gar nicht.
> wo unterscheiden sich "--host" und "--target"?
Diese Unterscheidung ist nur für codeerzeugende Programme (z.B.
Compiler) relevant. --host gibt an, auf welcher Architektur das
Programm läuft, und --target gibt an, für welche Architektur es
Code erzeugt. Zum Bleistift würde man
--build=i386-pc-linux-gnu
--host=sparc-sun-solaris2.8
--target=m68k-hp-hpux
verwenden, um auf einer x86-Maschine unter GNU/Linux einen Cross-
compiler zu bauen, der auf einer Sparc-Maschine unter Solaris 2.8
läuft und Code für eine HP-Maschine unter HP-UX erzeugt.
> wofuer steht genau "march", wofuer steht genau "mcpu"?
-mcpu=foo erzeugt Code, der für Prozessormodell foo optimiert ist,
aber auf jedem Prozessor derselben Familie läuft. Z.B. läuft mit
-mcpu=pentium3 compilierter Code auch auf einem Pentium II. -march=bar
hingegen bewirkt, das der Compiler Instruktionen für Prozessormodell
bar generiert. Solche Executables laufen dann nicht notwendigerweise
auf einem älteren Prozessormodell derselben Familie.
> und wenn march/mcpu fuer die prozessor-optimierung zustaendig sind, wie kann
> ich diese am besten setzten. ein 'make CFLAGS="-mcpu=i386 -march=i386"'
> wuerde in den meisten faellen irgentwelche flags (zb -Wall) aus dem
> Makeflile ueberschreiben.
Das ist aber die richtige Methode. Wenn der User durch das Setzen von
CFLAGS Optionen überschreiben kann, die das Programm zum Compilieren
braucht, ist das ein Bug. :-)
> zu guter letzt noch folgende frage: was ist wenn
> "gcc -O1 -mcpu=i486 -Wall -O3 -mcpu=i686 test.c -o test" erscheint? welche
> flags wuerde der compiler verwenden?
Wenn ich nicht irre, zählt immer die zuletzt angegebene Option.
Martin
Gunnar Ritter
> ich habe probleme mit der prozessor-optimierten compilation. [...]
> mit "file /usr/local/bin/mplayer" erhalte ich dagegen _jeweils_ "ELF 32-bit
> LSB executable, Intel 80386, version 1, dynamically linked (uses shared
> libs), stripped"
Mit
$ printf '18c\n\06\n.\nw\nq' | bvi -f /dev/stdin /usr/local/bin/mplayer
kannst Du ein getuntes 486-Binary erzeugen. Das bringt zwar genau
gar nichts, aber im Gegensatz zum Herumspielen mit irgendwelchen
Optimierungsswitches beeinflußt es die Performance auch nicht
negativ, solange der Kernel das Binary noch lädt.
Gunnar
Andre Homberg
hi,
hmm... - was genau macht diese zeile? was muesste ich fuer ein i586 oder
i686-getuentes Binary eingeben?
der kernel sollte solang er selbst fuerden entsprechenden prozessor
optimiert wurde keine probleme mitdem laden von optimierten anwendungen
haben...
gruss,
andre
Andre Homberg
> Das ist aber die richtige Methode. Wenn der User durch das Setzen von
> CFLAGS Optionen überschreiben kann, die das Programm zum Compilieren
> braucht, ist das ein Bug. :-)
dann waeren gut 50% der anwendungen ver'bugt :-)
eine kleines beispiel:
gd-2.0.1: "CFLAGS=-g -DHAVE_LIBPNG -DHAVE_LIBJPEG"
es waere kein problem hier hinten noch eine optimierungen anzuhaengen, aber
ich moechte die installationen scriptgesteuert durchfuehren. und
spaetestens wenn Makefiles dynamisch per configure erstellt werden, wuesst
ich nicht mehr wie ich hier scriptgesteuert die Makefiles anpassen sollte.
ein krasses beispiel ist php-4. da hat jeder funktionsnereich seine eigenen
Makefiles mit eigenen CFLAGS usw...
kann man hier einfach CFLAGS="-O3 -march=i686 -Wall" setzten? - koennte man
am obigen beispiel (gd-2.0.1) die CFLAGS einfach haendisch setzen?
im idealfall wuerd man bei root ein "export CFLAGS="-O3 -march=i686 -Wall"
in die "~/.bashrc" setzten...
gruss & thanxs,
andre
Andre Homberg
>
> Diese Unterscheidung ist nur für codeerzeugende Programme (z.B.
> Compiler) relevant. --host gibt an, auf welcher Architektur das
> Programm läuft, und --target gibt an, für welche Architektur es
> Code erzeugt. Zum Bleistift würde man
>
> --build=i386-pc-linux-gnu
> --host=sparc-sun-solaris2.8
> --target=m68k-hp-hpux
>
> verwenden, um auf einer x86-Maschine unter GNU/Linux einen Cross-
> compiler zu bauen, der auf einer Sparc-Maschine unter Solaris 2.8
> läuft und Code für eine HP-Maschine unter HP-UX erzeugt.
>
hi,
gleich noch ein paar fragen *g
ich versteh immer nochnicht den unterschied zwischen host und target. wozu
sollte ich ein projekt fuer eine HP-Maschiene compilieren, wenn das
programm auf einer sparc laufen soll?
wo muesste der developer host/target/build bereucksichtigen? direkt in den
sourcen, oder in den Makfefiles?
gruss,
andre
Rolf Magnus
> es waere kein problem hier hinten noch eine optimierungen anzuhaengen,
> aber ich moechte die installationen scriptgesteuert durchfuehren. und
> spaetestens wenn Makefiles dynamisch per configure erstellt werden, wuesst
> ich nicht mehr wie ich hier scriptgesteuert die Makefiles anpassen sollte.
> ein krasses beispiel ist php-4. da hat jeder funktionsnereich seine
> eigenen Makefiles mit eigenen CFLAGS usw...
> kann man hier einfach CFLAGS="-O3 -march=i686 -Wall" setzten?
Was kam denn bei deinem Test raus? Hat er die CFLAGS ignoriert? Hat das
Compilieren nicht funktioniert?
> - koennte
> man am obigen beispiel (gd-2.0.1) die CFLAGS einfach haendisch setzen?
> im idealfall wuerd man bei root ein "export CFLAGS="-O3 -march=i686 -Wall"
> in die "~/.bashrc" setzten...
Abgesehen davon, daß man als root nicht compiliert, könntest du sowas
machen.
Christian Weisgerber
> > wofuer steht genau "march", wofuer steht genau "mcpu"?
>
> -mcpu=foo erzeugt Code, der für Prozessormodell foo optimiert ist,
> aber auf jedem Prozessor derselben Familie läuft. Z.B. läuft mit
> -mcpu=pentium3 compilierter Code auch auf einem Pentium II. -march=bar
> hingegen bewirkt, das der Compiler Instruktionen für Prozessormodell
> bar generiert.
Ergänzend sei gesagt, dass bei GCC auch die Grundbedeutung dieser
Optionen architekturspezifisch ist. Obiges gilt auf i386. Auf alpha
und sparc z.B. erzeugt dagegen -mtune=foo allgemein lauffähigen,
aber für eine bestimmte Implementierung besser ausgelegten Code,
während -mcpu=foo auch auf Befehlssatzerweiterungen zurückgreift.
> > ich diese am besten setzten. ein 'make CFLAGS="-mcpu=i386 -march=i386"'
> > wuerde in den meisten faellen irgentwelche flags (zb -Wall) aus dem
> > Makeflile ueberschreiben.
>
> Das ist aber die richtige Methode.
Für Pakete mit autoconf-Gerüst ist das sowas wie »CFLAGS=bla
./configure«.
> Wenn der User durch das Setzen von CFLAGS Optionen überschreiben
> kann, die das Programm zum Compilieren braucht, ist das ein Bug.
POSIX verlangt, dass auf der Kommandozeile übergebene Variablen-
zuweisungen alle anderen Werte, auch die im Makefile, überschreiben
und rekursiv an aufgerufene make(1)s weitergegeben werden.
--
Christian "naddy" Weisgerber na...@mips.inka.de
Andre Homberg
> Was kam denn bei deinem Test raus? Hat er die CFLAGS ignoriert? Hat das
> Compilieren nicht funktioniert?
>
hi,
'make CFLAGS="-O3 -march=i386"' bricht mit der folgenden meldung ab:
"
....
cc -I. -I/usr/local/include -I/usr/include/X11 -I/usr/X11R6/include/X11
-I/usr/include pngtogd.o -o pngtogd -L/usr/local/lib -L/usr/lib/X11
-L/usr/X11R6/lib -L/usr/lib -lgd -lpng -lz -ljpeg -lm
pngtogd.o: In function `main':
pngtogd.o(.text+0x71): undefined reference to `gdImageCreateFromPng'
/usr/local/lib/libgd.so: undefined reference to `gdImagePngCtx'
/usr/local/lib/libgd.so: undefined reference to `gdImagePng'
/usr/local/lib/libgd.so: undefined reference to `gdImageCreateFromPngCtx'
collect2: ld returned 1 exit status
make: *** [pngtogd] Fehler 1
"
ohne haendisches setzen der CFLAGS klappt der kompilier-vorgang...
gruss,
andre
Martin Dickopp
>> Diese Unterscheidung ist nur für codeerzeugende Programme (z.B.
>> Compiler) relevant. --host gibt an, auf welcher Architektur das
>> Programm läuft, und --target gibt an, für welche Architektur es
>> Code erzeugt. Zum Bleistift würde man
>>
>> --build=i386-pc-linux-gnu
>> --host=sparc-sun-solaris2.8
>> --target=m68k-hp-hpux
>>
>> verwenden, um auf einer x86-Maschine unter GNU/Linux einen Cross-
>> compiler zu bauen, der auf einer Sparc-Maschine unter Solaris 2.8
>> läuft und Code für eine HP-Maschine unter HP-UX erzeugt.
> hi,
> gleich noch ein paar fragen *g
> ich versteh immer nochnicht den unterschied zwischen host und target. wozu
> sollte ich ein projekt fuer eine HP-Maschiene compilieren, wenn das
> programm auf einer sparc laufen soll?
Vielleicht hast Du nur eine Sparc-Maschine, Deine Kunden haben aber HPs
und möchten Dein Programm dort laufen lassen. Du compilierst es dann auf
Deiner Sparc, aber das Resultat läuft auf HP.
Regelmäßig kommt dies in der Praxis vor, wenn es sich beim Target um
irgendein Embedded System handelt. Programme für PDAs z.B. compilierst
Du nicht auf dem PDA selbst, sondern auf dem PC.
Martin
Martin Dickopp
> Martin Dickopp wrote:
>> Das ist aber die richtige Methode. Wenn der User durch das Setzen von
>> CFLAGS Optionen überschreiben kann, die das Programm zum Compilieren
>> braucht, ist das ein Bug. :-)
> dann waeren gut 50% der anwendungen ver'bugt :-)
> eine kleines beispiel:
Ich weiß nicht, wie Du auf 50% kommst. Ich überschreibe regelmäßig CFLAGS
und hatte damit bisher keine Probleme.
> gd-2.0.1: "CFLAGS=-g -DHAVE_LIBPNG -DHAVE_LIBJPEG"
Ja, das würde ich als Bug bezeichnen. Wenn das Programm -DHAVE_LIBPNG
-DHAVE_LIBJPEG braucht, könnte es diese Defines ja auch in eine andere
Makefile-Variable stecken, die der User nicht überschreiben darf (z.B.
DEFINES).
> und spaetestens wenn Makefiles dynamisch per configure erstellt
> werden, wuesst ich nicht mehr wie ich hier scriptgesteuert die
> Makefiles anpassen sollte.
Wenn Du die Environment-Variable CFLAGS setzt, bevor Du "configure"
aufrufst, wird deren Wert automatisch in allen generierten Makefiles
berücksichtigt.
Martin
Rolf Magnus
>>> --build=i386-pc-linux-gnu
>>> --host=sparc-sun-solaris2.8
>>> --target=m68k-hp-hpux
> Vielleicht hast Du nur eine Sparc-Maschine, Deine Kunden haben aber HPs
> und möchten Dein Programm dort laufen lassen. Du compilierst es dann auf
> Deiner Sparc, aber das Resultat läuft auf HP.
>
> Regelmäßig kommt dies in der Praxis vor, wenn es sich beim Target um
> irgendein Embedded System handelt. Programme für PDAs z.B. compilierst
> Du nicht auf dem PDA selbst, sondern auf dem PC.
Hier ging es aber doch darum, daß es drei verschiedene Angaben gibt, --host,
--build und --target. Zwei sind einleuchtend zum cross-compilieren, aber
wieso drei?
Rolf Magnus
> Rolf Magnus wrote:
>
>> Was kam denn bei deinem Test raus? Hat er die CFLAGS ignoriert? Hat das
>> Compilieren nicht funktioniert?
>>
>
> hi,
> 'make CFLAGS="-O3 -march=i386"' bricht mit der folgenden meldung ab:
So habe ich das noch nie angegeben. Ich mache immer sowas wie:
CFLAGS="-O3 -march=i386" ./configure
make
su -c "make install"
und das hat bei autoconf-basierten Sourcen bisher eigentlich immer
funktioniert.
Martin Dickopp
> Hier ging es aber doch darum, daß es drei verschiedene Angaben
> gibt, --host, --build und --target. Zwei sind einleuchtend zum
> cross-compilieren, aber wieso drei?
Wie ich bereits schrieb, ist die Unterscheidung dreier Architekturen
nur bei codeerzeugenden Prgrammen, z.B. Compilern, sinnvoll. Bei
einem Compiler spielen in der Tat drei Architekturen eine Rolle,
die potentiell verschieden sein können:
1. Die Architektur, auf der der Compiler compiliert wird ("build").
2. Die Architektur, auf der der Compiler läuft ("host").
3. Die Architektur, für die der Compiler Code erzeugt ("target").
Martin
Gunnar Ritter
>>> mit "file /usr/local/bin/mplayer" erhalte ich dagegen _jeweils_ "ELF
>>> 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses
>>> shared libs), stripped"
>> $ printf '18c\n\06\n.\nw\nq' | bvi -f /dev/stdin /usr/local/bin/mplayer
> hmm... - was genau macht diese zeile?
Sie sorgt u. A. dafür, daß «file» eine andere Ausgabe produziert.
Ich dachte, das hätte vielleicht eine positive Wirkung auf Dich.
> was muesste ich fuer ein i586 oder i686-getuentes Binary eingeben?
Das geht mit dieser Methode nicht. In /etc/magic oder auch
/usr/share/magic solltest Du eine Liste der möglichen Typen
finden.
> der kernel sollte solang er selbst fuerden entsprechenden prozessor
> optimiert wurde keine probleme mitdem laden von optimierten anwendungen
> haben...
OIC, Du kennst Dich offensichtlich aus. Wenn Du so ein Experte
bist, wieso fragst Du dann?
Gunnar
Gunnar Ritter
> Andre Homberg <hom...@fourmart.de> wrote:
>> gd-2.0.1: "CFLAGS=-g -DHAVE_LIBPNG -DHAVE_LIBJPEG"
> Ja, das würde ich als Bug bezeichnen. Wenn das Programm -DHAVE_LIBPNG
> -DHAVE_LIBJPEG braucht, könnte es diese Defines ja auch in eine andere
> Makefile-Variable stecken, die der User nicht überschreiben darf (z.B.
> DEFINES).
Der Unterschied zwischen Variablen bzw. Makros, «die der User nicht
überschreiben darf» und anderen existiert nur in Deiner Phantasie.
Es gibt keine verbindliche Festlegung von Makronamen in Makefiles
(mit Ausnahme der internal macros natürlich). Es gibt lediglich
default rules, und die heißen genau deshalb so. Entwickler können
Makros benutzen, wie sie wollen, und User, die das nicht verstehen,
sollten keine Software übersetzen.
Gunnar
Martin Dickopp
> Der Unterschied zwischen Variablen bzw. Makros, «die der User nicht
> überschreiben darf» und anderen existiert nur in Deiner Phantasie.
Viele Projekte halten sich aber an gewisse Coding Standards, und der
für das Übersetzen relevante Teil derselben liegt dem Sourcecode meist
in Gestalt eines Files README und/oder INSTALL bei.
In der Tat geben autoconf-generierte configure-Skripte unter anderem
folgendes aus, wenn man sie mit der Option --help aufruft:
| Some influential environment variables:
| CC C compiler command
| CFLAGS C compiler flags
| LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a
| nonstandard directory <lib dir>
| CPPFLAGS C/C++ preprocessor flags, e.g. -I<include dir> if you have
| headers in a nonstandard directory <include dir>
| CPP C preprocessor
|
| Use these variables to override the choices made by `configure' or to help
| it to find libraries and programs with nonstandard names/locations.
Darum bleibe bei meiner Meinung, daß es ein Bug ist, wenn man CFLAGS
bei Projekten, die autoconf verwenden, nicht beliebig setzen kann.
Abweichungen zwischen Dokumentation und tatsächlichem Verhalten sind
für mich Bugs.
> Es gibt keine verbindliche Festlegung von Makronamen in Makefiles
> (mit Ausnahme der internal macros natürlich).
Autoconf legt die Bedeutung bestimmter Makronamen fest. Wenn dem
Programmautor das nicht gefällt, soll er eben kein autoconf verwenden.
> Entwickler können Makros benutzen, wie sie wollen, und User, die das
> nicht verstehen, sollten keine Software übersetzen.
Unbestritten: Solange Entwickler ihre Software kostenlos abgeben und
somit keinerlei Gewährleistungspflichten unterliegen, haben sie das
Recht, beliebige Bugs in ihre Software einzubauen. ;-)
Martin
Gunnar Ritter
> Gunnar Ritter <g...@bigfoot.de> wrote:
>> Der Unterschied zwischen Variablen bzw. Makros, «die der User nicht
>> überschreiben darf» und anderen existiert nur in Deiner Phantasie.
> [...] | Some influential environment variables:
> | CC C compiler command
> | CFLAGS C compiler flags [...]
> Darum bleibe bei meiner Meinung, daß es ein Bug ist, wenn man CFLAGS
> bei Projekten, die autoconf verwenden, nicht beliebig setzen kann.
Da steht, daß CFLAGS von configure aus dem Environment übernommen
werden. Da steht nichts davon, daß sie mit den CFLAGS im Makefile
identisch sein müssen, und erst rechts nichts davon, daß letztere
über die make-Kommandozeile beliebig überschrieben werden können.
Gunnar
Andre Homberg
> Sie sorgt u. A. dafür, daß «file» eine andere Ausgabe produziert.
> Ich dachte, das hätte vielleicht eine positive Wirkung auf Dich.
wunderbar...
andre
Andre Homberg
hi,
nun hab ichs verstanden ;-)
gruss & thnxs,
andre
Andre Homberg
ui...
damit haette ich schonmal ein problem geklaert :-)
bei den programmen die ein statisches Makfefile benutzen kann ich die
eventuell genutzen "CFLAGS" ja haendisch erweitern.
gruss & thnxs,
andre
Gunnar Ritter
Um es Dir noch mal im Klartext zu sagen: Wenn Du nicht nachmessen
kannst, was die Prozessorswitches beim Compiler bringen, solltest
Du nicht mit ihnen herumspielen. Es kann genausogut sein, daß sie
Deine Programme langsamer machen. Du verschwendest daher nur Zeit
auf ein Glücksspiel, bei dem Du nicht mal sicher erkennen kannst,
ob Du gewonnen oder verloren hast.
Gunnar
Andre Homberg
weist du, vielleicht sind hier nicht alle poster kde-trolle!
vielleicht solltest du mal versuchen andere menschen ernst zu nehmen,
anstatt dich ueber ihre unwissenheit zu amuesieren, oder sie anzugreifen.
aber ich denke "moralpredigten" sind hier fehl am platz.
es geht mir um die prinzipielle funktionsweise. ich moechte kein
hochoptimiertes i686-system, sondern ein 100% gleich optimieretes system.
es ist doch _foelliger_ schwachfug anzunehmen durch mmx-optimierung auf der
console/x11 geschwindigkeitsvorteile spueren zu koennen...
ich moechte ein statisch compiliertes binary ohne probleme auf andere
rechner (zb i386-sx) kopieren koennen - dafuer benoetige ich ein sauber
compiliertes basis-system...
andre
Andre Homberg
>
> 1. Die Architektur, auf der der Compiler compiliert wird ("build").
> 2. Die Architektur, auf der der Compiler läuft ("host").
> 3. Die Architektur, für die der Compiler Code erzeugt ("target").
>
hi,
die letzten fragen :-)
wie sieht es aus wenn ich gcc mit:
"
CFLAGS="-O3 -march=i386"
./configure --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu
--target=i586-pc-linux-gnu
make
"
compiliere?
nach der oben beschriebenen erklaerung muesste fuers compilieren des "gcc"
legilich "i386"-instruktionen verwendet werden. beim zielsystem wuerden
auch nur maximal "i386"-instruktionen verwendet.
wie sieht es nun mit dem code aus den das so erstellte gcc generiert? werden
hier _grundsaetzlich_ i586-instruktionen verwendet? kann ich mit dem so
erstelltem gcc "i386"- oder "i686"-optimierte anwendungen kompilieren?
Was geschieht durch die 'zusaetliche' angabe der CFLAGS?
gruss,
andre
Felix von Leitner
> weist du, vielleicht sind hier nicht alle poster kde-trolle!
| User-Agent: KNode/0.7.1
ROTFL
Felix von Leitner
Warum probierst du das nicht einfach, anstatt hier unsere Zeit in
Anspruch zu nehmen? Wie kommst du überhaupt darauf, daß wir dir hier
nicht absichtlich die Unwahrheit reindrücken, damit du lernst, Sachen
selber zu klären, die du selber klären kannst?
Diese KDE-Trolle werden wirklich immer perfider.
Andre Homberg
du kannst natuerlich auch gern mutt verwenden. warum nicht gleich telnet?
ich bezweifle jedoch, ob du damit dann dein ziel schneller/besser erreichst
*g*
gruss,
andre
Rainer Weikusat
> "Felix von Leitner" wrote:
> > Thus spake Andre Homberg (hom...@fourmart.de):
> >> weist du, vielleicht sind hier nicht alle poster kde-trolle!
> >
> > | User-Agent: KNode/0.7.1
> >
> > ROTFL
>
> du kannst natuerlich auch gern mutt verwenden. warum nicht gleich
> telnet?
Geh weg.
Immo 'FaUl' Wehrenberg
> "Felix von Leitner" wrote:
> du kannst natuerlich auch gern mutt verwenden. warum nicht gleich telnet?
> ich bezweifle jedoch, ob du damit dann dein ziel schneller/besser erreichst
> *g*
Ich wuerde direkt 100EUR setzen das Felix damit schneller seine Ziele erreicht.
FaUl
end
This article does not support incompatible and broken newsreaders.
--
> Ein Router ist sowas ähnliches wie ein Hub. Er ermöglicht
> mehreren PCs den Internetzugang
Ein Roller ist so was wie ein Ufo, man kann sich damit fortbewegen.
"Sebastian" und "Andreas Hoffmann" in de.comm.technik.dsl
Rudolf Polzer
Mit mutt auf jeden Fall. Mit telnet ist es immerhin noch *möglich* und
hängt primär von seiner Tippgeschwindigkeit und deiner Klickgeschwindig-
keit ab.
--
Du fingst mit Einem heimlich an,
Bald kommen ihrer mehre dran,
Und wenn dich erst ein Dutzend hat,
So hat dich auch die ganze Stadt.
Martin Dickopp
> wie sieht es aus wenn ich gcc mit:
>
> "
> CFLAGS="-O3 -march=i386"
> ./configure --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu
> --target=i586-pc-linux-gnu
> make
> "
> compiliere?
Ich bin nicht sicher, würde aber vermuten, daß gcc die Architekturen
i386-pc-linux-gnu und i586-pc-linux-gnu gleich behandelt. Es handelt
sich ja eigentlich auch um die gleiche Architektur (GNU/Linux auf PC-
Hardware mit x86-komptiblem Prozessor).
Wenn es Dich sehr interessiert, wirf doch einen Blick in die Sourcen,
und berichte uns dann hier, was Du herausgefunden hast. :-)
Martin
Andre Homberg
es interssiert mich schon - ich werd sie mir mal naeher ansehen :-)
gruss,
andre
Michael Borchert
das ist mal wieder typisch, wie waers denn wenn man win98/2000 nutzt
und dennoch
mit linux arbeitet.
die zeit der consolenpuristen ist ja wohl mehr oder weniger laengst
vorbei.
manch einer hat da wohl etwas verschlafen.
schade das vermeintliche linux-guru's sich nicht auf ein normales
nivieau herablassen koennen und selbige schon als linexperten auf die
welt gekommen sind.
gruss mb