Liebe SuSE-Liste, Ich habe 3, eher grundsätzliche, Fragen an Euch, ich ich nicht mit den Handbüchern beantworten konnte. Da sie eng zusammengehören, möchte ich nicht für jedes einen Thread aufmachen. 1. Warum muss man Programme für Linux extra kompilieren? 2. Gibt es einen Unterschied, etwa in Programmschnelligkeit, Kompatibilität o.ä. zwischen der Kompilierung von *.tar.gz-Archiven und der Verwendung von vorkompilierten RPM-Paketen (ausser der einfacheren Installation und der unterschiedlichen Paketgrößen) 3. Ist es möglich/macht es Sinn, dem Compiler andere Optimierungsstufen zuzuweisen (z.B. für PII oder PIII) oder werden Programme dadurch buggy? Ich danke Euch für die Beantwortung der (zugegebenerweise nicht lebensbedrohlichen) Fragen! Günter
* Guenter Penk schrieb am 13.Jun.2001:
Ich habe 3, eher grundsätzliche, Fragen an Euch, ich ich nicht mit den Handbüchern beantworten konnte. Da sie eng zusammengehören, möchte ich nicht für jedes einen Thread aufmachen.
1. Warum muss man Programme für Linux extra kompilieren?
Jedes Programm muß auf jedes Betriebssystem kompiliert werden. Nur tun das bei Windows fast immer andere für Dich. Bei Linux eigentlich auch. Du hast auf Deinen CDs massenhaft fertig kompilierte Programme. Der Unterschied ist, bei Linux bekommst Du auch Quelltexte. Und Quelltexte müssen nun mal kompiliert werden, bevor sie benutzt werden können. Aber meistens gibt es auch rpm-Pakete, wo schon alles für Dich kompiliert wurde. Wenn Du allerdings allerneuste Programme haben möchtest, die noch in der Entwicklung sind, dann ist es doch klar, daß die noch nicht kompiliert vorliegen. Du mußt dabei auch bedenken, daß die Programme nicht nur auf PCs laufen sollen, sondern auf sehr viele Architekturen, bis hin zum Großrechner. Bei Windows und anderen kommerziellen Betriebssystemen bekommst Du solche Software erst gar nicht.
2. Gibt es einen Unterschied, etwa in Programmschnelligkeit, Kompatibilität o.ä. zwischen der Kompilierung von *.tar.gz-Archiven und der Verwendung von vorkompilierten RPM-Paketen (ausser der einfacheren Installation und der unterschiedlichen Paketgrößen)
Da Du bei der Kompilierung genau auf Deinen Rechner mit seiner Hardware eingehen kannst, kann das ganze ein klein wenig schneller werden. Ist doch klar, da die rpm auch auf einem 386er laufen können müssen, können sie nicht alle Performenc haben, die ein selbstkompiliertes Programm hat. Allerdings würde ich dann bei den Standardlibs anfangen. Und das willst Du nicht wirklich. Noch nicht. ;) Bernd -- ACK = ACKnowledge = Zustimmung | NAC = No ACknowledge = keine Zustimmung DAU = Dümmster Anzunehmender User | LOL = Laughing Out Loud = Lautes Lachen IIRC = If I Remember Correctly = Falls ich mich richtig erinnere OT = Off Topic = Am Thema (der Liste) vorbei |Zufallssignatur 11
Guenter Penk wrote:
Ich habe 3, eher grundsätzliche, Fragen an Euch, ich ich nicht mit den Handbüchern beantworten konnte. Da sie eng zusammengehören, möchte ich nicht für jedes einen Thread aufmachen.
1. Warum muss man Programme für Linux extra kompilieren?
Hmmm, Du hast unter Linux die Wahl, da Dir zu den allermeisten Programmen der Quellcode zur Verfuegung steht (im Gegensatz z.B. zum Windows-Betriebssystem). Entweder installierst Du vorcompilierte Pakete wie z.B. ein RPM-Paket -- da hat dann bereits jemand quasi fuer Dich das Programm compiliert und als RPM zusammengestellt (ausser Du nimmst SRPMs.... :-). Oder Du besorgst Dir den Source Code und compilierst selbst. Hat beides Vor- und Nachteile: RPM ist sicherlich gerade fuer Neulinge unter Linux oder Leute, die sich mit Compilern und den ganzen Optionen nicht so auskennen, einfacher, auch was Installation angeht. Sehr neue Programme oder Developer-Versionen bekommst Du meistens nur als reinen Quellcode, und mit autoconf und automake hat sich die Uebersetzung des Source Codes auch drastisch vereinfacht. Aber es bleibt fuer die meisten Leute trotzdem so eine Art Mysterium, obwohl es das eigentlich nicht muesste :-) Punkt 2. unten spielt sicherlich bei den Betrachtungen auch eine Rolle.....
2. Gibt es einen Unterschied, etwa in Programmschnelligkeit, Kompatibilität o.ä. zwischen der Kompilierung von *.tar.gz-Archiven und der Verwendung von vorkompilierten RPM-Paketen (ausser der einfacheren Installation und der unterschiedlichen Paketgrößen)
Prinzipiell solltest Du RPM Pakete installieren, die fuer Dein System bestimmt sind, insbesondere fuer Deine glibc. Je nachdem, was der Autor des RPMs beim Compilieren des Programmes fuer Optionen verwendet hat, sind die Programme mehr oder weniger fuer Dein System (Prozessor) optimiert. Bei manchen Programmen kann eine Optimierung sehr viel bringen, bei anderen Programm wiederum spielt es keine so grosse Rolle. Abhilfe wuerde da z.B. das Verwenden von Source-RPMs schaffen, da diese auf Deinem System compiliert werden und Du quasi ueber gewisse Konfigurationsmoeglichkeiten noch Einfluss darauf hast. Oder eben direkt *.tar.gz nehmen und compilieren.
3. Ist es möglich/macht es Sinn, dem Compiler andere Optimierungsstufen zuzuweisen (z.B. für PII oder PIII) oder werden Programme dadurch buggy?
Prinzipiell sollte das Programm, wenn es ordentlich geschrieben ist, nicht 'buggy' werden. Ob es was bringt, haengt u.a. davon ab, ob das Programm von speziellen Features der unterschiedlichen Prozessoren Gebrauch macht. Ich denke, es wird selten lohnen, sein gesamtes System neu zu compilieren, nur um eine bessere Optimierung hinzubekommen. Einige auf dieser Liste haben AFAIR schonmal damit experimentiert, z.B. Xfree neu zu compilieren, um damit Geschwindigkeits- oder andere Vorteile zu bekommen, Vielleicht koennen die Dir ja noch weitere Hinweise geben. Hoffe, das ist so alles korrekt, was ich geschrieben habe. Im Zweifelsfalle ist es IMHO und IIRC.... :-) MfG, Thomson -- Thomas Hertweck, Geophysicist Geophysical Institute, University of Karlsruhe Hertzstr. 16, D-76187 Karlsruhe, Germany
Am Mittwoch, 13. Juni 2001 19:56 schrieb Guenter Penk:
Ich habe 3, eher grundsätzliche, Fragen an Euch, ich ich nicht mit den Handbüchern beantworten konnte. Da sie eng zusammengehören, möchte ich nicht für jedes einen Thread aufmachen.
1. Warum muss man Programme für Linux extra kompilieren?
Jeder Prozessor hat einen eigenen Sprachschatz an Maschinenbefehlen, da aber kaum jemand in dieser Maschinensprache programmiert (hab das früher mal auf dem C128 mal gemacht), steckt ein Wandler dazwischen, der das was der Programmierer schreibt (Source Code) in für den Prozessor verständliche Befehle umsetzt (Binary). Bei Assembler (leichter lesbarer Maschinencode mit Macromöglichkeiten) ist es der Assembler, bei Hochsprachen der Compiler und bei Scriptsprachen der Interpreter. Abgesehen von der dritten Gattung geschieht diese Wandlung einmalig, unter Linux meist mit einem "./configure", "make" und "make install" bis letztendlich ausführbare Software vorliegt. Bei Scriptsprachen erfolgt die Umwandlung während der Ausführung, Befehl für Befehl (mit entsprechenden Geschwindigkeitsnachteilen). Dann gibt es noch "Zwittersprachen", die sich beider Techniken bedienen, wie z.B. Java. Das ist so auch auf anderen Systemen (Windows, MacOS, Amiga, ...) und nicht Linuxspezifisch. Das Besondere an Linux ist nur, dass es ein OpenSource System ist, das bedeutet, dass die Programmme nicht nur in der ausführbaren Version, sondern auch im Source Code zur Verfügung stehen. Wer will kann sie seinen Bedürfnissen anpassen, Fehler bereinigen, neue Funktionen hinzufügen usw. und letztendlich natürlich auch einfach nur übersetzen um Ausführbare Programme zu erhalten. In der regel stehen die ausführbaren Varianten aber zumindestens für IA32-Prozessoren (x86) zur Verfügung. Linux läuft aber nicht nur auf Intel/AMD Kisten, daher ist es kaum einem Programmierer möglich, Ausführbare Varianten für alle möglichen Prozessoren zu erstellen (Sparc, PPC, Mips, Alpha, 68k, ...), allein deshalb ist es immer gut, den Source Code zu haben und selbst übersetzen zu können. Schon mal versucht aktuelle Software für die PPC-Version von Windows NT zu finden?
2. Gibt es einen Unterschied, etwa in Programmschnelligkeit, Kompatibilität o.ä. zwischen der Kompilierung von *.tar.gz-Archiven und der Verwendung von vorkompilierten RPM-Paketen (ausser der einfacheren Installation und der unterschiedlichen Paketgrößen)
Du hast in jedem Fall den Vorteil, dass das Programm genau auf Deinen Rechner hin zugeschnitten ist, also für die Libraries compiliert wurde, die auch auf Deinem System installiert sind, das kann Probleme vermeiden helfen. Insbesondere die libc/glibc verursacht da Probleme, so wird ein unter SuSE 7.1 compiliertes Programm kaum unter SuSE 6.4 und sicher nicht unter 5.x laufen. Vorteile kann es auch durch individuelle Konfiguration geben. Ein "./configure --help" fördert oft recht interessante Möglichkeiten zu Tage um etwa gewünschte Funktionen zu aktivieren und nicht benötigte zu deaktivieren. Das kann Vorteile in der Ausführungsgeschwindigkeit haben. Geschwindigkeitsvorteile können auch durch spezielle Compiler-Optionen (Pentium optimiert, Atlon optimiert, ...) bieten. Distributoren sind natürlich interessiert, ein Programm auf möglichst vielen Rechnern problemlos laufen lassen zu köennen, weshalb Programme (im IA32-Umfeld) meist i80386 kompatibel übersetzt wurden.
3. Ist es möglich/macht es Sinn, dem Compiler andere Optimierungsstufen zuzuweisen (z.B. für PII oder PIII) oder werden Programme dadurch buggy?
Jede Compiliereinstellung ruft Änderungen am erzeugten Programmcode hervor, es sind mit Sicherheit nicht alle Kombinationen mit allen denkbaren Source Code Varianten ausgetestet, von daher ist es nicht auszuschliessen, dass man sich einen Fehler einfängt. -- Machs gut | http://www.iiv.de/schwinde/buerger/tremmel/ | http://www.knightsoft.de Manfred | http://www.knightsoft-net.de
On Don, 14 Jun 2001, Manfred Tremmel wrote:
Am Mittwoch, 13. Juni 2001 19:56 schrieb Guenter Penk:
1. Warum muss man Programme für Linux extra kompilieren? [Gute Einfuehrung]
Linux läuft aber nicht nur auf Intel/AMD Kisten, daher ist es kaum einem Programmierer möglich, Ausführbare Varianten für alle möglichen Prozessoren zu erstellen (Sparc, PPC, Mips, Alpha, 68k, ...), allein deshalb ist es immer gut, den Source Code zu haben und selbst übersetzen zu können.
Jup. z.B. hab ich einen shell-Account auf nem SunOS/Sparc, auf dem wget fehlte (aber nicht ftp). Also via ftp mal eben die Quellen von wget besorgt, tar -x...; ./configure --prefix=$HOME; make; make install; feddich. Und alles via ssh. Mach das mal auf ner Win* Kiste mit nem Win-Tool wie z.B. GetRight oder GoZilla, das wirst du kaum auf nem SunOS/Sparc zum laufen bekommen.
vermeiden helfen. Insbesondere die libc/glibc verursacht da Probleme, so wird ein unter SuSE 7.1 compiliertes Programm kaum unter SuSE 6.4 und sicher nicht unter 5.x laufen.
Ack. 7.0er "laufen" auf meiner 6.2 (glibc 2.1.3), >= 7.1 (glibc 2.2.x) meist nicht.
Jede Compiliereinstellung ruft Änderungen am erzeugten Programmcode hervor, es sind mit Sicherheit nicht alle Kombinationen mit allen denkbaren Source Code Varianten ausgetestet, von daher ist es nicht auszuschliessen, dass man sich einen Fehler einfängt.
Wobei man dann immer noch die Moeglichkeit hat, "einen Gang runterzu- schalten" und die Quellen mit einer weniger aggressiven Optimierung, z.B. '-O -march=i586' doch noch zum laufen zu bringen. -dnh -- Excerpt from a conversation with a friend, early in my unix odyssey: "So now I've got all these floppy-sized archive pieces, and I haven't been able to figure out what program I'm supposed to use to concat-- er, never mind." [void in asr]
Hallo Manfred, * Manfred Tremmel schrieb am 14.Jun.2001:
Am Mittwoch, 13. Juni 2001 19:56 schrieb Guenter Penk:
Ich habe 3, eher grundsätzliche, Fragen an Euch, ich ich nicht mit den Handbüchern beantworten konnte. Da sie eng zusammengehören, möchte ich nicht für jedes einen Thread aufmachen.
1. Warum muss man Programme für Linux extra kompilieren?
Jeder Prozessor hat einen eigenen Sprachschatz an Maschinenbefehlen, da aber kaum jemand in dieser Maschinensprache programmiert (hab das früher mal auf dem C128 mal gemacht), steckt ein Wandler dazwischen, der das was der Programmierer schreibt (Source Code) in für den Prozessor verständliche Befehle umsetzt (Binary). Bei Assembler (leichter lesbarer Maschinencode mit Macromöglichkeiten) ist es der Assembler, bei Hochsprachen der Compiler und bei Scriptsprachen der Interpreter. Abgesehen von der dritten Gattung geschieht diese Wandlung einmalig, unter Linux meist mit einem "./configure", "make" und "make install" bis letztendlich ausführbare Software vorliegt. Bei
Nun ja, das hast Du ein wenig mißverständlich geschrieben. configure und make sind Hilfsprogramme. Der eigentliche Compiler ist bei Linux meist gcc. Compiliert wird beim make - Aufruf. Bernd -- Probleme mit dem Drucker? Schon die Druckercheckliste beachtet? http://localhost/doc/sdb/de/html/drucker-howto.html | Auch lesenswert: Oder schon das Drucker-HOWTO gelesen? | man lpr file://usr/shar/doc/howto/de/DE-Drucker-HOWTO.txt.gz | Zufallssignatur 3
Bernd Brodesser wrote:
[...] Nun ja, das hast Du ein wenig mißverständlich geschrieben. configure und make sind Hilfsprogramme. Der eigentliche Compiler ist bei Linux meist gcc. Compiliert wird beim make - Aufruf.
Eigentlich, so habe ich das mal gelernt, ist gcc auch nicht "der Compiler", sondern ein Rahmenprogramm, was selbstaendig z.B. Preprocessor (cpp), Compiler (cc1), Assembler (as) oder Linker (ld) aufrufen kann. Je nach Optionen (z.B. -E oder -c) und Suffixes der Eingangsprogramme (z.B. .c oder .o) wird dann entschieden, welche Schritte unternommen werden muessen. Make (auf Linux, auf anderen Systemen meist gmake genannt) ist ein Programm, was beim Aufruf ein sog. Makefile auswertet. Dort sind meist Abhaengigkeiten einzelner Programmteile voneinander aufgefuehrt und Regeln, wie Teile des Programms (oder das komplette Programm) neu erstellt oder upgedatet werden koennen. Meist werden Makefiles in Zusammenhang mit zu compilierenden Programmen eingesetzt (neuerdings zusammen mit autoconf und automake), allerdings ist das Einsatzgebiet weitaus groesser, z.B. auch im Zusammenspiel mit LaTeX o.ae. Gruesse, Thomson -- Thomas Hertweck, Geophysicist Geophysical Institute, University of Karlsruhe Hertzstr. 16, D-76187 Karlsruhe, Germany
* Thomas Hertweck schrieb am 14.Jun.2001:
Bernd Brodesser wrote:
[...] Nun ja, das hast Du ein wenig mißverständlich geschrieben. configure und make sind Hilfsprogramme. Der eigentliche Compiler ist bei Linux meist gcc. Compiliert wird beim make - Aufruf.
Eigentlich, so habe ich das mal gelernt, ist gcc auch nicht "der Compiler", sondern ein Rahmenprogramm, was selbstaendig z.B. Preprocessor (cpp), Compiler (cc1), Assembler (as) oder Linker (ld) aufrufen kann. Je nach Optionen (z.B. -E oder -c) und Suffixes der
Ja, obwohl, kann man auch den Compiler cc1? getrennt aufrufen? Wußte ich nicht.
Eingangsprogramme (z.B. .c oder .o) wird dann entschieden, welche Schritte unternommen werden muessen. Make (auf Linux, auf anderen Systemen meist gmake genannt) ist ein Programm, was beim Aufruf ein
Nö, gmake ist der GNUmake, der bei Linux einfach make heißt. Der Original UNIX make heißt einfach nur make. Kann sein, daß er vom gmake abgelöst wurde. Aber das, was Du beschreibst kann er auch alles.
sog. Makefile auswertet. Dort sind meist Abhaengigkeiten einzelner Programmteile voneinander aufgefuehrt und Regeln, wie Teile des Programms (oder das komplette Programm) neu erstellt oder upgedatet werden koennen. Meist werden Makefiles in Zusammenhang mit zu compilierenden Programmen eingesetzt (neuerdings zusammen mit autoconf und automake), allerdings ist das Einsatzgebiet weitaus groesser, z.B. auch im Zusammenspiel mit LaTeX o.ae.
Ein weitere Einsatzmöglichkeit wäre im Zusammenhang mit /etc/rc.config.d Oder muß ich es verstehen, daß alle nochmal ausgeführt werden, wenn man nur eine geändert hat? Bernd -- Bitte die Etikette beachten: http://home.t-online.de/~f.walle/etikette.html Bitte Realnamen angeben, kein Vollquoting, kein Html, PGP oder Visitenkarten benutzen. Signatur mit "-- " abtrennen, bei Antworten "Re: " voranstellen, sonst nichts. |Zufallssignatur 4
Bernd Brodesser wrote:
* Thomas Hertweck schrieb am 14.Jun.2001:
Bernd Brodesser wrote:
[...] Nun ja, das hast Du ein wenig mißverständlich geschrieben. configure und make sind Hilfsprogramme. Der eigentliche Compiler ist bei Linux meist gcc. Compiliert wird beim make - Aufruf.
Eigentlich, so habe ich das mal gelernt, ist gcc auch nicht "der Compiler", sondern ein Rahmenprogramm, was selbstaendig z.B. Preprocessor (cpp), Compiler (cc1), Assembler (as) oder Linker (ld) aufrufen kann. Je nach Optionen (z.B. -E oder -c) und Suffixes der
Ja, obwohl, kann man auch den Compiler cc1? getrennt aufrufen? Wußte ich nicht.
cc1 steht auf jeden Fall nicht im Standard-Pfad, d.h. durch Aufruf von cc1 in der Shell passiert erst mal nicht viel :-) Habe mir gerade mal ein kleines Programm hello.c erstellt und mit "/usr/lib/gcc-lib/i486-suse-linux/2.95.3/cc1 hello.c" compiliert. Da fehlt natuerlich der Preprocessor Aufruf, aber als Output erhaelt man eine Datei hello.s (Assembler Source). Aber damit kann ich dann nicht mehr viel anfangen, da hoeren meine Kenntnisse dann auf *g*....
[...] Nö, gmake ist der GNUmake, der bei Linux einfach make heißt. Der Original UNIX make heißt einfach nur make. Kann sein, daß er vom gmake abgelöst wurde. Aber das, was Du beschreibst kann er auch alles.
Oh, vielleicht haben wir uns da missverstanden, ich glaube, wir meinen das Gleiche. Auf den meisten Unix-Systemen muss GNU make ueber "gmake" aufgerufen werden, nur bei Linux ist make = gmake. Makefiles des Standard Unix make Befehls sind mitunter nicht kompatibel zu den Makefiles von GNU make, das wollte ich eigentlich nur kurz andeuten. Die grundlegenden Funktionen beherrschen natuerlich beide. Wahrscheinlich wirds langsam OT, obwohl, sehr interessant, das Thema.... :-) Gruesse, Thomson -- Thomas Hertweck, Geophysicist Geophysical Institute, University of Karlsruhe Hertzstr. 16, D-76187 Karlsruhe, Germany
* Thomas Hertweck schrieb am 14.Jun.2001:
Auf den meisten Unix-Systemen muss GNU make ueber "gmake" aufgerufen werden, nur bei Linux ist make = gmake. Makefiles des Standard Unix make Befehls sind mitunter nicht kompatibel zu den Makefiles von GNU make, das wollte ich eigentlich nur kurz andeuten. Die grundlegenden Funktionen beherrschen natuerlich beide.
Ja. Ich kenne nur die alten UNIX makes, weiß nicht was die heute noch so alles bieten. Verglichen mit den alten kann GNU make natürlich eine ganze Menge mehr. Aber bei Licht betrachtet, die wichtigen Sachen beherrschte auch schon das alte make.
Wahrscheinlich wirds langsam OT, obwohl, sehr interessant, das Thema.... :-)
wieso ist das OT? Steht doch niergends geschrieben, daß das hier eine Anfängerliste ist. Bernd -- Bei Fragen an die Liste erst mal nachschauen, ob es diese Frage nicht schon einmal gegeben hat. Ein Archiv der Liste findest Du auf: http://lists.suse.com/archives/suse-linux |Zufallssignatur 7
Hallo Bernd, hallo Liste, On Thu, 14 Jun 2001 at 19:24 +0200, Bernd Brodesser wrote:
wieso ist das OT? Steht doch niergends geschrieben, daß das hier eine Anfängerliste ist.
ACK!! Wer sagt, dass das nicht andere interessiert? Mich z. B. interessiert es sehr, wenn ich auch mangels Wissen nichts darüber schreiben kann. Anderen geht es vermutlich ähnlich. Gruß, Bernhard -- -------------------------------------------------------------------- ------------> http://www.links2linux.de <----------- --------------------------------------------------------------------
Am Don, 14 Jun 2001, schrieb Thomas Hertweck:
Bernd Brodesser wrote:
* Thomas Hertweck schrieb am 14.Jun.2001:
Bernd Brodesser wrote:
[...] Nun ja, das hast Du ein wenig mißverständlich geschrieben. configure und make sind Hilfsprogramme. Der eigentliche Compiler ist bei Linux meist gcc. Compiliert wird beim make - Aufruf.
Eigentlich, so habe ich das mal gelernt, ist gcc auch nicht "der Compiler", sondern ein Rahmenprogramm, was selbstaendig z.B. Preprocessor (cpp), Compiler (cc1), Assembler (as) oder Linker (ld) aufrufen kann. Je nach Optionen (z.B. -E oder -c) und Suffixes der
Ja, obwohl, kann man auch den Compiler cc1? getrennt aufrufen? Wußte ich nicht.
cc1 steht auf jeden Fall nicht im Standard-Pfad, d.h. durch Aufruf von cc1 in der Shell passiert erst mal nicht viel :-) Habe mir gerade mal ein kleines Programm hello.c erstellt und mit "/usr/lib/gcc-lib/i486-suse-linux/2.95.3/cc1 hello.c" compiliert. Da fehlt natuerlich der Preprocessor Aufruf, aber als Output erhaelt man eine Datei hello.s (Assembler Source). Aber damit kann ich dann nicht mehr viel anfangen, da hoeren meine Kenntnisse dann auf *g*.... Jetzt kannst Du vielleicht das Programm as aufrufen und ihm die Assembler-Sourcen übergeben... Wenn ich kompiliere (C++), zeigt top in schönem Wechsel cc1plus und as als die ressourcenfressenden Programme an...
Gruß Christoph -- Christoph Maurer - Paul-Röntgen-Straße 7 - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Christoph Maurer wrote:
Am Don, 14 Jun 2001, schrieb Thomas Hertweck: [...]
cc1 steht auf jeden Fall nicht im Standard-Pfad, d.h. durch Aufruf von cc1 in der Shell passiert erst mal nicht viel :-) Habe mir gerade mal ein kleines Programm hello.c erstellt und mit "/usr/lib/gcc-lib/i486-suse-linux/2.95.3/cc1 hello.c" compiliert. Da fehlt natuerlich der Preprocessor Aufruf, aber als Output erhaelt man eine Datei hello.s (Assembler Source). Aber damit kann ich dann nicht mehr viel anfangen, da hoeren meine Kenntnisse dann auf *g*....
Jetzt kannst Du vielleicht das Programm as aufrufen und ihm die Assembler-Sourcen übergeben...
Ja, schon.... - aber schau Dir (falls Du es selbst mal versuchst) die Datei hello.s an. Die sieht ungefaehr wie folgt aus: ================================ .file "hello.c" .version "01.01" gcc2_compiled.: .section .rodata .LC0: .string "Hallo Welt!\n" .text .align 16 .globl main .type main,@function main: pushl %ebp movl %esp,%ebp subl $8,%esp addl $-12,%esp pushl $.LC0 call printf addl $16,%esp xorl %eax,%eax jmp .L2 .p2align 4,,7 .L2: movl %ebp,%esp popl %ebp ret .Lfe1: .size main,.Lfe1-main .ident "GCC: (GNU) 2.95.2 19991024 (release)" ================================ ... und damit kann _ich_ definitiv nicht mehr viel anfangen. Ich kenne mich bei Assembler nur absolut rudimentaer aus (um nicht zu sagen, gar nicht) :-))
Wenn ich kompiliere (C++), zeigt top in schönem Wechsel cc1plus und as als die ressourcenfressenden Programme an...
Yep. Bei C wird cc1 aufgerufen, bei C++ cc1plus. Gruesse, Thomson -- Thomas Hertweck, Geophysicist Geophysical Institute, Karlsruhe University (TH) Hertzstr. 16, D-76187 Karlsruhe, Germany
Am Fre, 15 Jun 2001, schrieb Thomas Hertweck:
Christoph Maurer wrote:
Am Don, 14 Jun 2001, schrieb Thomas Hertweck: [...]
cc1 steht auf jeden Fall nicht im Standard-Pfad, d.h. durch Aufruf von cc1 in der Shell passiert erst mal nicht viel :-) Habe mir gerade mal ein kleines Programm hello.c erstellt und mit "/usr/lib/gcc-lib/i486-suse-linux/2.95.3/cc1 hello.c" compiliert. Da fehlt natuerlich der Preprocessor Aufruf, aber als Output erhaelt man eine Datei hello.s (Assembler Source). Aber damit kann ich dann nicht mehr viel anfangen, da hoeren meine Kenntnisse dann auf *g*....
Jetzt kannst Du vielleicht das Programm as aufrufen und ihm die Assembler-Sourcen übergeben...
Ja, schon.... - aber schau Dir (falls Du es selbst mal versuchst) die Datei hello.s an. Die sieht ungefaehr wie folgt aus: [Listing hello.s] ... und damit kann _ich_ definitiv nicht mehr viel anfangen. Ich kenne mich bei Assembler nur absolut rudimentaer aus (um nicht zu sagen, gar nicht) :-))
Bei mir ist es auch nicht viel besser, ich kenne ein paar Assemblerbefehle und habe im Studium auf dem Papier auch ein bißchen Assembler schreiben müssen, aber das wars. Habe jetzt mal folgendes gemacht: Mit cpp hello.c Preprozessor aufgerufen > Ausgabe auf stdout Mit cc1 hello.c bekomme ich das Assemblerfile hello.s mit as -o hello.o hello.s bekomme ich ein Objektfile Linken habe ich bisher nicht hinbekommen. Gruß Christoph -- Christoph Maurer - Paul-Röntgen-Straße 7 - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
* Christoph Maurer schrieb am 15.Jun.2001:
Bei mir ist es auch nicht viel besser, ich kenne ein paar Assemblerbefehle und habe im Studium auf dem Papier auch ein bißchen Assembler schreiben müssen, aber das wars.
Habe jetzt mal folgendes gemacht: Mit cpp hello.c Preprozessor aufgerufen > Ausgabe auf stdout
Ich meine, mal gehört zu haben, daß die Ausgabe hello.i heißen sollte. Weiß aber jetzt nicht mehr, welches Programm dies benutzt. cpp jedenfalls nicht, daß gibt ja nach Stdout aus.
Mit cc1 hello.c bekomme ich das Assemblerfile hello.s mit as -o hello.o hello.s bekomme ich ein Objektfile
Linken habe ich bisher nicht hinbekommen.
Der Linker heißt ld. Bernd -- LILO funktioniert nicht? Hast Du /etc/lilo.conf verändert und vergessen, lilo aufzurufen? Ist Deine /boot-Partition unter der 1024 Zylindergrenze? Bei anderen LILO Problemen mal in der SDB nachschauen: http://localhost/doc/sdb/de/html/rb_bootdisk.html |Zufallssignatur 6
On Fre, 15 Jun 2001, Bernd Brodesser wrote:
* Christoph Maurer schrieb am 15.Jun.2001:
Bei mir ist es auch nicht viel besser, ich kenne ein paar Assemblerbefehle und habe im Studium auf dem Papier auch ein bißchen Assembler schreiben müssen, aber das wars.
Habe jetzt mal folgendes gemacht: Mit cpp hello.c Preprozessor aufgerufen > Ausgabe auf stdout
Ich meine, mal gehört zu haben, daß die Ausgabe hello.i heißen sollte. Weiß aber jetzt nicht mehr, welches Programm dies benutzt. cpp jedenfalls nicht, daß gibt ja nach Stdout aus.
Doch (und bei C++ .ii). Nur muss man das eben (wie bei cc1 auch) angeben: dh@slarty[2]:/tmp/test (0) $ cat << EOF > hello.c
#include
int main() { printf("Hello World!\n"); return 0; } EOF dh@slarty[2]:/tmp/test (0) $ cpp hello.c -o hello.i dh@slarty[2]:/tmp/test (0) $ /usr/local/lib/gcc-lib/i686-pc-linux-gnu/p gcc-2.95.3/cc1 hello.i -o hello.s dh@slarty[2]:/tmp/test (0) $ as hello.s -o hello.o dh@slarty[2]:/tmp/test (0) $ /usr/local/lib/gcc-lib/i686-pc-linux-gnu/p gcc-2.95.3/collect2 -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o h ello /usr/lib/crt1.o /usr/lib/crti.o /usr/local/lib/gcc-lib/i686-pc-lin ux-gnu/pgcc-2.95.3/crtbegin.o -L/usr/local/lib/gcc-lib/i686-pc-linux-gn u/pgcc-2.95.3 -L/usr/local/lib /tmp/cc18B6jp.o -lgcc -lc -lgcc /usr/loc al/lib/gcc-lib/i686-pc-linux-gnu/pgcc-2.95.3/crtend.o /usr/lib/crtn.o dh@slarty[2]:/tmp/test (0) $ ./hello Hello World! dh@slarty[2]:/tmp/test (0) $
(gnadenlos bei 72 Zeichen umgebrochen) Einfach mal make als "make CC="gcc -v" aufrufen ;) Wie das jetzt direkt mit ld geht weiss ich jetzt auch nicht, mit den crt*.o Dateien muss aber auf jeden Fall gelinkt werden... Naeheres sollte sich in 'info ld' finden lassen. -dnh --
Can you SysAdmins tell me what might go on in a typical day? Hours of endless frustration punctuated by moments of sheer terror. -- Saul Tannenbaum
Hallo David, * David Haller schrieb am 15.Jun.2001:
On Fre, 15 Jun 2001, Bernd Brodesser wrote:
* Christoph Maurer schrieb am 15.Jun.2001:
Bei mir ist es auch nicht viel besser, ich kenne ein paar Assemblerbefehle und habe im Studium auf dem Papier auch ein bißchen Assembler schreiben müssen, aber das wars.
Habe jetzt mal folgendes gemacht: Mit cpp hello.c Preprozessor aufgerufen > Ausgabe auf stdout
Ich meine, mal gehört zu haben, daß die Ausgabe hello.i heißen sollte. Weiß aber jetzt nicht mehr, welches Programm dies benutzt. cpp jedenfalls nicht, daß gibt ja nach Stdout aus.
Doch (und bei C++ .ii). Nur muss man das eben (wie bei cc1 auch) angeben:
dh@slarty[2]:/tmp/test (0) $ cat << EOF > hello.c
#include
int main() { printf("Hello World!\n"); return 0; } EOF dh@slarty[2]:/tmp/test (0) $ cpp hello.c -o hello.i
Nun gut, aber angeben kann man natürlich alles Mögliche. Da könnte es auch cpp hello.c -o tux.penguin heißen. Aber irgend ein Programm braucht doch das .i. Ihr, Eilert und Du, seid doch auch der Meinung, daß es i heißen muß. Make war es auch nicht. mit make hello.i kann make ohne Makefile nichts anfangen. Bernd -- Probleme mit dem Drucker? Schon die Druckercheckliste beachtet? http://localhost/doc/sdb/de/html/drucker-howto.html | Auch lesenswert: Oder schon das Drucker-HOWTO gelesen? | man lpr file://usr/shar/doc/howto/de/DE-Drucker-HOWTO.txt.gz | Zufallssignatur 3
Hallo Compilerforscher, Bernd Brodesser schrieb:
Hallo David,
* David Haller schrieb am 15.Jun.2001:
On Fre, 15 Jun 2001, Bernd Brodesser wrote:
* Christoph Maurer schrieb am 15.Jun.2001:
[Welche Compilerphasen haben mit .i-Dateien zu tun?]
Nun gut, aber angeben kann man natürlich alles Mögliche. Da könnte es auch cpp hello.c -o tux.penguin heißen. Aber irgend ein Programm braucht doch das .i. Ihr, Eilert und Du, seid doch auch der Meinung, daß es i heißen muß. Make war es auch nicht. mit make hello.i kann ^^^^^^^^ make ohne Makefile nichts anfangen.
In dieselbe Kerbe schlag ich auch! Der cpp erzeugt "auf Wunsch" (bei ganz alten Unices ohne viel Plattenplatz auch grundsätzlich) eine .i-Datei, die dann vom Compiler (und evtl. separatem Optimierer) in die Assembler-Quelle .s umgesetzt wird. (So hatte ich das 1990 bei meinem Interactive Unix kennengelernt - autsch, geoutet) Schönes Wochenende, Norbert
Christoph Maurer wrote:
Bei mir ist es auch nicht viel besser, ich kenne ein paar Assemblerbefehle und habe im Studium auf dem Papier auch ein bißchen Assembler schreiben müssen, aber das wars.
Habe jetzt mal folgendes gemacht: Mit cpp hello.c Preprozessor aufgerufen > Ausgabe auf stdout ^^^^^^^^^^^^^^^^^^^^ So wird das aber nicht weiterverarbeitet!
Mit cc1 hello.c bekomme ich das Assemblerfile hello.s mit as -o hello.o hello.s bekomme ich ein Objektfile
Linken habe ich bisher nicht hinbekommen.
Preprocessor-Aufruf....: thertw@einstein [test] gcc -E -o hello.i hello.c Compiler-Aufruf....: thertw@einstein [test] gcc -S -o hello.s hello.i Assembler-Aufruf....: thertw@einstein [test] gcc -c -o hello.o hello.s Linker-Aufruf....: thertw@einstein [test] gcc -o hello hello.o Programm-Aufruf....: thertw@einstein [test] ./hello Hallo Welt! Beim direkten Aufruf der einzelnen Programme cpp, cc1, as, und ld musst Du mitunter noch einiges mehr uebergeben, was Du beim Aufruf ueber gcc nicht musst. Vermutlich brauchst Du beim Linken noch /lib/crt[01n].o (start-up routine), oder aehnliches. Oder Du musst den Entry-Point angeben. Aber damit habe ich mich auch noch nicht beschaeftigt.... :-) Gruesse, Thomson -- Thomas Hertweck, Geophysicist Geophysical Institute, Karlsruhe University (TH) Hertzstr. 16, D-76187 Karlsruhe, Germany
Am Donnerstag, 14. Juni 2001 13:52 schrieb Bernd Brodesser:
Nun ja, das hast Du ein wenig mißverständlich geschrieben. configure und make sind Hilfsprogramme. Der eigentliche Compiler ist bei Linux meist gcc. Compiliert wird beim make - Aufruf.
Du hast recht, das hab ich etwas zu schwammig formuliert. Der Compilevorgang wird mit "./configure" vorbereitet/konfiguriert mit "make" die Übersetzung angestossen und mit "make install" das fertig compilierte Programm installiert. Hinter den drei Schritten verbergen sich dann entsprechende Scripts, die die für den Compilevorgang und Linkvorgang nötigen Programme anstossen, was unter Linux in den meisten Fällen die Programme aus der GNU Compiler Collection (gcc) erledigen. Was konkret abläuft, ist dem Makefile zu entnehmen. Ich hoffe, das war diesmal klarer ausgedrückt ;-) PS: Und da sich SuSE wohl nicht in der Lage sieht XFree86- oder Mozilla- Updates für die PPC-Version anzubieten, bin ich recht froh, dass man seine Sachen selbst compilieren kann. Sonst würd mein Powerbook heut noch ohne AA-Fonts und Mozilla 0.9.1 dastehen ... -- Machs gut | http://www.iiv.de/schwinde/buerger/tremmel/ | http://www.knightsoft.de Manfred | http://www.knightsoft-net.de
participants (8)
-
B.Brodesser＠t-online.de -
Bernhard Walle -
Christoph Maurer -
David Haller -
Guenter Penk -
Manfred Tremmel -
Norbert Kordts -
Thomas Hertweck