Datum: 28.04.2008 16:47
Hallo! Ich schäme mich fast dafür, aber es ist nun mal so, dass es nicht funktioniert und ich euch deshalb um Rat frage ;) Ich habe etwas in C programmiert (unter Linux (das ich eigentlich nicht sehr mag, aber da ist alles dabei)). Das Ganze besteht aus zwei Teilen: - test.c mit main-funktion / test.h mit einigen Konstanten drin und - meine_lib.c enthält einige Funktionen / meine_lib.h wieder einige Konstanten In test.c habe ich ganz oben mit #include "meine_lib.h" das eingebunden (liegt alles selben Verzeichnis). Er scheint die Datei beim Präprozessieren auch zu finden (also wenn ich absichtlich einen nicht vorhandenen Dateinamen angebe, dann gibts einen Error, dass er die Datei nicht findet). Allerdings erhalte ich wenn ich mit gcc test.c kompilieren will eine Fehlermeldung, dass er die Funktionen welche in meine_lib.c sind nicht finden kann... Hab auch versucht die Definitionen der Funktionen (also die einzelnen Funktionsnamen mit Argumenten und mit ';' am Schluss) in die meine_lib.h zu kopieren, allerdings ohne Erfolg. Was kann noch falsch sein? Oder muss ich dem GCC-dings explizit die meine_lib.h auch noch angeben? Macht für mich keinen Sinn, da dann die #include Anweisung überflüssig ist. Wo könnte es noch Fallstricke geben?
Datum: 28.04.2008 17:00
Anscheinend unfähiger wrote: > Allerdings erhalte ich wenn ich mit gcc test.c kompilieren will eine > Fehlermeldung, dass er die Funktionen welche in meine_lib.c sind nicht > finden kann... Du musst auch meine_lib.c kompilieren und natürlich müssen die beiden COmpilate auch zusammengelinkt werden. Am einfachsten geht das, wenn du beim gcc AUfruf einfach beides angibst. gcc test.c meine_lib.c > muss ich dem GCC-dings explizit die meine_lib.h auch noch angeben? Macht > für mich keinen Sinn, da dann die #include Anweisung überflüssig ist. Die ist keineswegs überflüssig. Wenn der Compiler gerade an test.c arbeitet, weiss er nichts von meine_lib.c. Erst dadurch dass test.c die meine_lib.h includiert wird ihm mitgeteilt, was sich in meine_lib.c abspielt. Jedes *.c File wird für sich compiliert, unabhängig von allen anderen.
Datum: 28.04.2008 18:05
OK, auch wenn es momentan irgendie nicht viel Sinn (für mich) macht, ich werde es akzeptieren ;) Dann ergeben sich allerdings neue Fragen: - Spielt die Reihenfolge der Aufrufe eine Rolle? (Jetzt kommt meine Interpretation des ganzen: nein, weil er alles zuerst kompiliert, dann guckt er (wer auch immer das tut) in welcher .c-Datei eine main-Funktion ist und nimmt die als oberstes Element an und Linkt dann alle Funktionen zusammen die dort (und in den verlinkten Funktionen) benötigt werden?!) - Wie geht dann das mit dem Optimieren von Codes? Dies tut ja der Compiler, kann der also nicht über mehrere Funktionen hinweg optimieren, weil er ja nicht weiss in was für einem Umfeld die Funktion verwendet wird? - Eine Möglichkeit der Optimierung ist das Inlining, wie kann dann das von statten gehen? - Werden nur einzelne Funktionen verlinkt und nicht verwendete weggelassen? Also, mehr fragen wie am Anfang... Vielen Dank auf jeden Fall, jetzt funktionierts problemlos!!!
Datum: 28.04.2008 19:42
Anscheinend unfähiger wrote: > OK, auch wenn es momentan irgendie nicht viel Sinn (für mich) macht, ich > werde es akzeptieren ;) Stell dir einfach mal ein Projekt vor, dass aus 2000 Source Code Files (also *.c Files) besteht. Es ist dann irgendwie unsinnig, wenn bei jeder kleinsten Änderung alle 2000 Dateien neu kompliliert werden müssen. Wieviel einfacher und zeitsparender ist es doch, wenn nur die tatsächlich betroffenen *.c Dateien kompiliert werden und dann aus diesen Einzelteilen (+ die bereits complierten Dateien, die sich aber nicht verändert haben) ein neues Programm zusammengebaut wird. Dazu ist aber eine Grundvoraussetzung, dass jedes .c unabhängig von allen anderen .c compilierbar ist. > Dann ergeben sich allerdings neue Fragen: > - Spielt die Reihenfolge der Aufrufe eine Rolle? (Jetzt kommt meine > Interpretation des ganzen: nein, richtig > weil er alles zuerst kompiliert, richtig > dann > guckt er (wer auch immer das tut) das macht der Linker > in welcher .c-Datei eine main-Funktion Nicht .c Datei. Die sind zu diesem Zeitpunkt schon uninteressant. Es werden die Ergebnisse der Compilierung der .c Dateien zum Programm zusammengelinkt. .c -> .o -----+ +---> Programm .c -> .o -----+ ^ ^ | | das macht der Linker | das macht der Compiler > ist und nimmt die als oberstes Element an und Linkt dann alle Funktionen > zusammen die dort (und in den verlinkten Funktionen) benötigt werden?!) Yep. > - Wie geht dann das mit dem Optimieren von Codes? Dies tut ja der > Compiler, kann der also nicht über mehrere Funktionen hinweg optimieren, Über Funktionen schon, solange sie im selben .c sind. > weil er ja nicht weiss in was für einem Umfeld die Funktion verwendet > wird? richtig. > - Eine Möglichkeit der Optimierung ist das Inlining, wie kann dann das > von statten gehen? Um inlinen zu können, muss der Compiler logischerweise den Inhalt (also den Funktionstext) einer Funktion kennen. Kennt er den nicht -> kein inlining. > - Werden nur einzelne Funktionen verlinkt und nicht verwendete > weggelassen? Kommt auf den Linker an. Meistens: ja
Datum: 28.04.2008 20:25
Vielen Dank!!! Jetzt ist so einiges klarer...
Antwort schreiben
Die Angabe einer Email-Adresse ist freiwillig. Wenn Sie automatisch per Email über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
- Suchfunktion und Betreffsuche benutzen - vielleicht gibt es schon einen ähnlichen Beitrag
- Aussagekräftigen Betreff wählen
- Im Betreff angeben um welchen Controllertyp es geht (AVR, PIC, ...)
- Groß- und Kleinschreibung verwenden
- Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
- JPEG-Dateien (.jpg) nur für Fotos verwenden, Schaltpläne, Screenshots usw. als PNG oder GIF anhängen
Formatierung (mehr Informationen...)
- [c]C-Code[/c]
- [avrasm]AVR-Assembler-Code[/avrasm]
- [pre]vorformatierter Text (z.B. Code in anderen Sprachen)[/pre]
- [math]Formel in LaTeX-Syntax[/math]
- [[Titel]] - Link zu Artikel


