Hi,
ich portiere derzeit mein CFramework und eine andere Bibliothek von dem
MS Compiler zu GCC (die MS Unterstützung für C ist nicht die Beste),
also die Dateien zu einem Eclipse Projekt kopiert und kompiliert. So
weit so gut. Nachdem ich jedoch ein Testprogramm geschrieben habe,
jammert der Linker an vielen Stellen, dass dort eine Funktion ist, zu
dem er keine Referenz findet. Nur warum? Die Pfade und Bibliotheken sind
drin und der Compiler und der Linker haben sonst nichts zu meckern.
Mir ist aufgefallen, dass der Linker kein Problem mit der CFramework Lib
hat, sondern mit der anderen Lib, welche dass das CFramework benutzt.
Und genau dort liegt das Problem. Der Linker findet die Referenz von den
CFramework Funktionen nicht, die (und nur die) in der anderen Bibliothek
verwendet werden, das eigentliche Programm hat keine Problem das
CFramework zu benutzen.
Ich hoffe, dass ich das Problem ausreichend schildern konnte, denn am
Code kanns nicht liegen.
Vielen Dank für eure Hilfe!
Christopher C. schrieb:> Nachdem ich jedoch ein Testprogramm geschrieben habe,> jammert der Linker an vielen Stellen, dass dort eine Funktion ist, zu> dem er keine Referenz findet.
Mach's mal bitte konkret, am besten mit einem kurzen Beispielprogramm
sowie mit der Kommandozeile, mit der der Linker aufgerufen wird.
Christopher C. schrieb:> Und dann gehts los mit Fehlern :(.
Ja, mit welchen denn?
Und wie sind all die vielen Bibliotheken, die du da hast, denn
entstanden? (libCFramework.a, libCEngine.a)
Gehört nun main.o zu libCEngine.a?
Also diese drei Codedateien gehören je zu einem Projekt.
CFramework.c -> CFramework
CEngine.c -> CEngine (braucht CFramework)
main.c -> Programm (linkt CFramework und CEngine)
Christopher C. schrieb:> Also diese drei Codedateien gehören je zu einem Projekt.
Das allein hat doch aber noch nichts mit Bibliotheken zu tun.
Mir dünkt, du schmeißt hier gerade sämtliche Begriffe durcheinander.
Compiliere diese drei Dateien jeweils separat, und dann linkst du
die erhaltenen Objekte zusammen. Nix "Bibliothek", keine -l
Optionen (außer denen für Systembibliotheken, soweit erforderlich).
gcc -o executable main.o CFramework.o CEngine.o
Fertig ist die Laube.
Früher war's mal so, dass der Linker statische Bibliotheken nur von
links nach rechts einmal sequenziell abgearbeitet hat. Man musste also
die Bibliotheken in der richtigen Reihenfolge beim Linken angeben und
ggf. auch mal eine Bibliothek mehrfach angeben, z.B. wenn A und B sich
gegenseitig benötigen "-lA -lB -lA".
Nein, du verstehtst mich falsch, das war nur ein Beispiel, die Projekte
haben weit mehr als nur eine Codedatei. Bibliotheken daraus zu machen,
macht schon Sinn.
Am Anfang hab ich die drei Projekte schon mal für den GCC gemacht, das
funktionierte auch. Danach wechselte ich dann zu Visual Studio 2010, da
ich hörte, dass es die beste IDE für C++ ist (somit eigentlich auch für
C). Allerdings stellte sich dann heraus, dass die IDE wirklich gut, der
Compiler aber für C Müll ist. Ich schrieb aber trotzdem noch ein wenig
weiter an meinem Bibliotheken und nun will ich wieder zurück zu GCC.
Hier noch mal die ganze Ausgabe:
aha,
Christopher C. schrieb:> Am Anfang hab ich die drei Projekte schon mal für den GCC gemacht, das> funktionierte auch. Danach wechselte ich dann zu Visual Studio 2010, da> ich hörte, dass es die beste IDE für C++ ist (somit eigentlich auch für> C). Allerdings stellte sich dann heraus, dass die IDE wirklich gut, der> Compiler aber für C Müll ist. Ich schrieb aber trotzdem noch ein wenig> weiter an meinem Bibliotheken und nun will ich wieder zurück zu GCC.
deshalb steigt man von einem funktionierenden System um,
Jörg Wunsch schrieb:>>... -lCFramework -lCEngine ...Falsche Reihenfolge.>> Bzw. siehe Beitrag "Re: Linken in einer Lib schlägt fehl">> Konkret also:> -lCFramework -lCEngine -lCFramework......
muss ich mir mal merken, wenn ich wieder zuviel zu tun haben
> Allerdings stellte sich dann heraus, dass die IDE wirklich gut, der> Compiler aber für C Müll ist
Woran machst Du das fest?
> -lCFramework -lCEngine -lCFramework
Kann man machen. Hat aber den Nachteil daß es kompliziert/aufwändig
werden kann wenn man noch mehr Komponenten mit diesen Abhängigkeiten
verwenden will.
Aber diese zirkulären Abhängigkeiten sind häufig ein Anzeichen für ein
schlechtes Design. Überleg mal, ob Du es nicht anders aufteilen kannst.
Wenn das nicht geht (oder zu kompliziert/aufwändig ist) kannst Du auch
die Linker-Gruppen vom GCC/LD verwenden.
-Wl,--start-group -lCFramework -lCEngine -Wl,--end-group
dann versucht der LD diese Abhängikeiten selbst aufzulösen.
> Aber diese zirkulären Abhängigkeiten sind häufig ein Anzeichen für ein> schlechtes Design. Überleg mal, ob Du es nicht anders aufteilen kannst.
Danke für die Rückmeldung. Aber so schlimm is es nicht, ich kann einfach
mit:
-lCEngine -lCFramework
linken. Die Reihenfolge war einfach falsch.
Vielen Dank für eure Bemühungen ;).
mfg
Dirk Dörr schrieb:>> Allerdings stellte sich dann heraus, dass die IDE wirklich gut, der>> Compiler aber für C Müll ist>> Woran machst Du das fest?
Microsoft investiert meines Wissens praktisch nichts mehr in C, d. h.
sie sind bei ANSI C89 / ISO C90 mit ihrer Entwicklung stehengeblieben.
Inzwischen haben wir nun schon C11 …
Dirk Dörr schrieb:>> Microsoft investiert meines Wissens praktisch nichts mehr in C> Na ja, veraltet ok, aber Müll...
Wenn etwas hoffnungslos veraltet ist, wird es irgendwann Müll. Erst,
wenn es 20 Jahre lang bereits als Müll galt, sodass es kaum noch
irgendwas davon auf der Welt gibt, bekommt es wieder Wert. ;-)
