Kompilieren ohne alle Dateien anzugeben

hallo,

es ist ja so, dass man prototypen in den headern hat, die eigentliche funktonen aber im normalen quelltext.

wenn ich also was compilieren will, dann muss ich das so machen:
gcc main.c functions1.c functions2.c -o main

meine frage ist: wenn ich eine headerdatei aus einer lib verwende, dann muss ich die .c-dateien auch nicht angeben, das macht der compiler automatisch.

genauso ists mit der stdlib, wenn ich "stdio.h" verwende, ich muss ja nicht
gcc main.c stdio.c
schreien, sondern nur "gcc main.c"

ich habe nun meine eigene lib geschrieben, muss aber, immer wenn ich aus dieser lib funktionen, bzw. header einbinde, die ganzen quelldateien in der compilerzeile mit angeben. wie machen das andere libs, bzw. die stdlib? also dass der compiler die benötigten dateien quasi automatisch miteinbezieht, wenn header inkludiert werden?

C++ Forumbot

Dieser Thread wurde von Moderator/in SeppJ aus dem Forum C (C89, C99 und C11) in das Forum Compiler- und IDE-Forum verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

SeppJ

Die Standardbibliothek wird unsichtbar automatisch mitgelinkt. "Linken" ist aber schon das richtige Stichwort. Daher unbedingt mal nachschlagen, wenn dir das nichts sagt.

Effektiv willst du deine Bibliothek erst einmal zu Objektcode übersetzen (Beim gcc der Compilerschalter -c) und diesen dann in einer Bibliotheksdatei (einfach ein ar-Archiv) sammeln. Diese Datei packst du dann in einen Pfad, wo sie vom Linker gefunden wird (beim GCC ist gcc gleichzeitig das Aufrufkommando für Präprozessor, Compiler und Linker, obwohl das eigentlich drei getrennte Vorgänge sind) und gibst sie mittels -l als Bibliothek an.

Ähnlich willst du das später auch ab einer gewissen Projektgröße mit den ganzen Quelldateien deines Projektes machen. Du willst schließlich nicht bei jeder kleinen Änderung in irgendeiner Datei jedes Mal alles neu compilieren müssen. Daher übersetzt du jede einzelne Datei in Objektcode; compilierst immer nur die geänderten Dateien neu; und linkst dann alles zusammen. Makefiles helfen dir, diesen Teil zu automatisieren. Buildsysteme helfen dir, den Gesamtvorgang zu automatisieren.

Vermutlich hast du nur die Hälfte verstanden . Ist eben ein komplexes Thema und einige der genannten Stichwörter (Makefile, Buildsystem) sind eigene Welten über die man dicke Bücher schreiben kann (sind aber später sehr nützlich). Hier empfiehlt sich wirklich mal learning by doing. Schnapp dir ein paar fremde Bibliotheken und schau dir an, wie man diese benutzt, damit du ein Gefühl für den Vorgang Compilieren->Linken bekommst. Installier ein paar Programme, die du selber aus dem Sourcecode übersetzt, um ein Gefühl für die Grundlagen von Buildsystemen und Makefiles zu bekommen.

doch doch ich versteh schon:

1. alle sourcecodes mittels "gcc -c <datei.c> -o <datei.o>" compilieren
2. "ar -cvq myLib.lib <alle *.o-dateien>"
3. programm, das lib benutzt, compilieren mit "gcc main.c -lmyLib -o main"

--> so meinst du das, nicht wahr?

p.s.: wie ist das eigentlich unter linux, wo es so viele unterstützte architekturen gibt? da kann ja nicht zu 100% gewährt werden, dass die lib am ende funktioniert?

SeppJ

so??? schrieb:

doch doch ich versteh schon:

1. alle sourcecodes mittels "gcc -c <datei.c> -o <datei.o>" compilieren
2. "ar -cvq myLib.lib <alle *.o-dateien>"
3. programm, das lib benutzt, compilieren mit "gcc main.c -lmyLib -o main"

--> so meinst du das, nicht wahr?

Ja, so ungefähr. Die Namensgebung kommt mir etwas komisch vor. Was ist das, Windows? Da musst du mal gucken, ob und wie das mit den Konventionen des -l-Schalters passt.

p.s.: wie ist das eigentlich unter linux, wo es so viele unterstützte architekturen gibt? da kann ja nicht zu 100% gewährt werden, dass die lib am ende funktioniert?

Die Bibliothek muss selbstverständlich für jede Architektur neu erstellt werden. Es gibt auch noch gewisse Namensgebungs-/Ordnerkonventionen, wenn man Bibliotheken für mehrere Architekturen installiert hat (z.B. für Crosscompiling oder für x64-Systeme, die auch i386-Bibliotheken unterstützen), aber ich nehme mal an, die Erklärung kann ich mir mangels Bedarf sparen.
Es kann jedoch auch zu Problemen mit unterschiedlichen Systemen unter der gleichen Architektur kommen, daher ist es üblich, Bibliotheken für jedes System neu zu übersetzen. Distributionen vereinheitlichen viele wichtige Aspekte eines Linuxsystems und sind daher in der Lage, vorcompilierte Bibliotheken fix und fertig als Gesamtpaket auszuliefern.

ja, das mit "myLib.lib" ist natürlich nicht der richtige name

ich hab im internet irgendwo gelesen, dass auch der microsoft c++ compiler das "ar" format für static libs nutzt. warum? ich dachte, die von ms wollten mit linux nix zu tun haben? das format kommt nämlich von linux...

meine lib ist nicht so groß (8 dateien oder so). ich glaub, da reicht ein (selbstgeschriebenes) sh-script? wie man das schreibt, weiß ich. aber wie kann ich überprüfen, ob der gcc installiert ist?

SeppJ

threadstarter schrieb:

ich hab im internet irgendwo gelesen, dass auch der microsoft c++ compiler das "ar" format für static libs nutzt. warum? ich dachte, die von ms wollten mit linux nix zu tun haben? das format kommt nämlich von linux...

Warum nicht? Dein Argument ist doch Unsinn.

meine lib ist nicht so groß (8 dateien oder so). ich glaub, da reicht ein (selbstgeschriebenes) sh-script? wie man das schreibt, weiß ich. aber wie kann ich überprüfen, ob der gcc installiert ist?

Das ist genau das, wofür Buildautomatisierung erfunden wurde. Anstatt das selber schlecht hinzufrickeln guckst du dir lieber gleich an, wie das geht. Ein Projekt mit 8 Dateien ist wunderbar zum Lernen geeignet, weil man da wohl kaum eines der komplizierteren Features benötigt, gleichzeitig aber schon klar die Vorzüge erkennen kann.

SeppJ schrieb:

Warum nicht? Dein Argument ist doch Unsinn.

naja, weil man halt von ms gewöhnt ist, dass sie ihr zeug selbst entwickeln (und es für besser verkaufen, als es ist).
aber ok, anscheinend ist das hier nicht so.