gcc: Fehlermeldung: findet Funktionen nicht --> ?

[Anscheinend unfähiger (Gast)]

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?

[Karl H. (kbuchegg)]

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.

[Anscheinend unfähiger (Gast)]

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!!!

[Karl H. (kbuchegg)]

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

[Anscheinend unfähiger (Gast)]

Vielen Dank!!! Jetzt ist so einiges klarer...