ENGLISH VERSION |
|
Links | | | Forum | | | Kommentare | | | News melden |
Chat | | | Umfragen | | | Newsticker | | | Archiv |
amiga-news.de Forum > Programmierung > Anfängerfrage: Wie linke ich eine .a Datei ? | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
1 -2- | [ - Beitrag schreiben - ] |
20.02.2007, 19:20 Uhr Der_Wanderer Posts: 1229 Nutzer |
Ok, also meine test.library geht. Ich linke jetzt allerdings mit dem GCC im aktuellen Verzeichnis: GCC -noixemul -nostartfiles -o test.library #?.o d.h. mein Library code stimmt schonmal. Wenn ich genau so meine dumb.library linke, bekomme ich "nur" noch folgendes: (die Link Fehler mit dem duh_... sind von mir, ich habe éine .o Datei noch nicht korrekt erzeugt, aber die Mathematischen Befehle und die Libbase Sachen stören mich...) 32.Work:Sourcecodes/dumb> gcc -noixemul -nostartfiles -o dumb.library #?.o libdumb68k.a dumb_funcs.o(.text+0x8e): undefined reference to 'undload_duh' dumb_funcs.o(.text+0xb0): undefined reference to 'duh_start_sigrenderer' dumb_funcs.o(.text+0x176): undefined reference to 'duh_end_sigrenderer' libdumb68k.a(.text+0x1160): undefined reference to 'duh_start_sigrenderer' libdumb68k.a(.text+0x118a): undefined reference to 'duh_sigrenderer_get_n_channels' libdumb68k.a(.text+0x11ea): undefined reference to 'duh_sigrenderer_generate_samples' libdumb68k.a(.text+0x1342): undefined reference to 'duh_sigrenderer_get_n_channels' libdumb68k.a(.text+0x135e): undefined reference to 'duh_sigrenderer_get_position' libdumb68k.a(.text+0x137a): undefined reference to 'duh_end_sigrenderer' libdumb68k.a(.text+0x2cea): undefined reference to 'exit' libdumb68k.a(.text+0x553a): undefined reference to 'pow' libdumb68k.a(.text+0x55ba): undefined reference to 'exp' libdumb68k.a(.text+0x680a): undefined reference to 'pow' libdumb68k.a(.text+0x687e): undefined reference to 'pow' libdumb68k.a(.text+0xa70c): undefined reference to 'pow' libdumb68k.a(.text+0xa7a6): undefined reference to 'pow' libdumb68k.a(.text+0xa8a8): undefined reference to 'pow' libdumb68k.a(.text+0xbb80): more undefined references to 'pow' follow libdumb68k.a(.text+0xcd68): undefined reference to 'duh_encapsulate_raw_sigrenderer' libdumb68k.a(.text+0xcd8c): undefined reference to 'duh_get_raw_sigrenderer' libdumb68k.a(.text+0xd762): undefined reference to 'log' libdumb68k.a(.text+0xd77a): undefined reference to 'log' libdumb68k.a(.text+0xd7ae): undefined reference to 'floor' libdumb68k.a(.text+0xd972): undefined reference to 'pow' libdumb68k.a(.text+0x107e2): undefined reference to 'pow' libdumb68k.a(.text+0x10812): undefined reference to 'pow' libdumb68k.a(.text+0x11bc4): undefined reference to 'pow' libdumb68k.a(.text+0x11be8): undefined reference to 'floor' libdumb68k.a(.text+0x12850): undefined reference to 'floor' libdumb68k.a(.text+0x1827c): undefined reference to 'floor' libdumb68k.a(.text+0x1895a): undefined reference to 'floor' libdumb68k.a(.text+0x189ae): undefined reference to 'floor' libdumb68k.a(.text+0x1fcf6): more undefined references to 'floor' follow /gg/lib/libnix/libnix.a(__mulsi3.o)(.text+0x8): undefined reference to '__UtilityBase' /gg/lib/libnix/libnix.a(__stdio.o)(.text+0x40): undefined reference to 'exit' /gg/lib/libnix/libnix.a(abort.o)(.text+0x38): undefined reference to 'exit' /gg/lib/libnix/libnix.a(__floatsidf.o)(.text+0x4): undefined reference to '__MathIeeeDoubBasBase' /gg/lib/libnix/libnix.a(__muldf3.o)(.text+0x6): undefined reference to '__MathIeeeDoubBasBase' /gg/lib/libnix/libnix.a(__adddf3.o)(.text+0x6): undefined reference to '__MathIeeeDoubBasBase' /gg/lib/libnix/libnix.a(__truncdfsf2.o)(.text+0x4): undefined reference to '__MathIeeeDoubTransBase' /gg/lib/libnix/libnix.a(__subsf3.o)(.text+0x4): undefined reference to '__MathIeeeSingBasBase' /gg/lib/libnix/libnix.a(__divsf3.o)(.text+0x4): undefined reference to '__MathIeeeSingBasBase' /gg/lib/libnix/libnix.a(__eqsf2.o)(.text+0x4): undefined reference to '__MathIeeeSingBasBase' /gg/lib/libnix/libnix.a(__mulsf3.o)(.text+0x4): undefined reference to '__MathIeeeSingBasBase' /gg/lib/libnix/libnix.a(__addsf3.o)(.text+0x4): undefined reference to '__MathIeeeSingBasBase' /gg/lib/libnix/libnix.a(__fixsfsi.o)(.text+0x4): more undefined references to '__MathIeeeSingBasBase' follow /gg/lib/libnix/libnix.a(__divsi3.o)(.text+0x14): undefined reference to '__UtilityBase' /gg/lib/libnix/libnix.a(__divdf3.o)(.text+0x6): undefined reference to '__MathIeeeDoubBasBase' /gg/lib/libnix/libnix.a(__fixdfsi.o)(.text+0x4): undefined reference to '__MathIeeeDoubBasBase' /gg/lib/libnix/libnix.a(__extendsfdf2.o)(.text+0x4): undefined reference to '__MathIeeeDoubTransBase' /gg/lib/libnix/libnix.a(__udivsi3.o)(.text+0x14): undefined reference to '__UtilityBase' /gg/lib/libnix/libnix.a(freopen.o)(.text+0x3a): undefined reference to '__DOSBase' /gg/lib/libnix/libnix.a(freopen.o)(.text+0x4a): undefined reference to '__DOSBase' /gg/lib/libnix/libnix.a(freopen.o)(.text+0x74): undefined reference to '__DOSBase' /gg/lib/libnix/libnix.a(freopen.o)(.text+0x80): undefined reference to '__DOSBase' /gg/lib/libnix/libnix.a(raise.o)(.text+0x82): undefined reference to 'exit' /gg/lib/libnix/libnix.a(open.o)(.text+0x96): undefined reference to '__DOSBase' /gg/lib/libnix/libnix.a(open.o)(.text+0xf0): undefined reference to '__DOSBase' /gg/lib/libnix/libnix.a(open.o)(.text+0x108): undefined reference to '__DOSBase' /gg/lib/libnix/libnix.a(open.o)(.text+0x146): undefined reference to '__DOSBase' /gg/lib/libnix/libnix.a(open.o)(.text+0x180): undefined reference to '__DOSBase' /gg/lib/libnix/libnix.a(open.o)(.text+0x1b0): more undefined references to '__DOSBase' follow /gg/lib/libnix/libnix.a(open.o)(.text+0x26c): undefined reference to '_WBenchMsg' /gg/lib/libnix/libnix.a(open.o)(.text+0x274): undefined reference to '__DOSBase' /gg/lib/libnix/libnix.a(open.o)(.text+0x2c0): undefined reference to '__DOSBase' /gg/lib/libnix/libnix.a(open.o)(.text+0x2d8): undefined reference to '__DOSBase' /gg/lib/libnix/libnix.a(open.o)(.text+0x234): undefined reference to 'exit' /gg/lib/libnix/libnix.a(__seterrno.o)(.text+0xc): undefined reference to '__DOSBase' collect2: ld returned 1 exit status 32.Work:Sourcecodes/dumb> -- Thilo Köhler, Author von: HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
20.02.2007, 20:13 Uhr whose Posts: 2156 Nutzer |
@Der_Wanderer: Uff, wie war das nochmal? "-lm" dürfte die Referenzen zu pow etc. auflösen. Wie Du an die DOSBase kommst, müßtest Du eigentlich wissen Da kann Dir aber "-lauto" evtl. weiterhelfen, wenn Du die dos.library nicht von Hand öffnen magst. Grüße -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233 [ - Antworten - Zitieren - Direktlink - ] |
20.02.2007, 20:46 Uhr Holger Posts: 8116 Nutzer |
Zitat: AAArgh!! Was soll denn -lauto helfen, wenn man es mit Libraries zusammenlinkt?! Einmal den freien Fall genießen? mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
20.02.2007, 20:56 Uhr Holger Posts: 8116 Nutzer |
@Der_Wanderer: Also, die Funktionen pow, exp, floor, etc. lassen sich durch Linken mit der Math-Bibliothek (-lm) beheben, besser noch, durch die richtige CPU-Option, um die FPU zu benutzen, weil man sich dann __MathIeeeSingBasBase und __MathIeeeDoubBasBase usw. sparen kann. Um DOSBase und UtilityBase kommt man vielleicht nicht drum herum. Musst Du halt in Deiner Library definieren und auch zum richtigen Zeitpunkt initialisieren. Die Referenzen zu exit sind allerdings sehr bedenklich. Die bestätigen, was ich schon vorher gesagt habe: stdio und Amiga-Libraries passen nicht zusammen. Du kannst das Problem nur umgehen, in dem Du die stdio-Routinen in Library-kompatibler Weise selbst implementierst und dazulinkst. Dann werden die libnix-Varianten nicht genommen. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
20.02.2007, 21:26 Uhr whose Posts: 2156 Nutzer |
Zitat: Äh, zum Thema Standard-C-Lib-Funktionen und Amiga-Shared-Libraries habt ihr doch schon einiges gesagt. Und Der_Wanderer scheint mit dem GCC noch nicht richtig klarzukommen. Nachher fragt er bei einem ganz normalen Programm nochmal nach, wie man diese Referenzen auflöst. Da kann man doch mal erwähnen, daß er die meisten dieser Referenzen per -lauto "erschlagen" kann, wenn er die Libbases nicht von Hand deklarieren und initialisieren will? Das ich auf die Gefahr dieser Lösung bei Amiga-Shared-Libs nicht eingegangen bin, war aber mein Versäumnis. Verzeihung. Grüße -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233 [ - Antworten - Zitieren - Direktlink - ] |
21.02.2007, 16:02 Uhr gni Posts: 1106 Nutzer |
Zitat:Wie oft muß noch wiederholt werden, das -lauto bei libnix (-noixemul) _nicht_ verwendet werden muß!? Das wurde bereits x-mal durchgekaut. Genau wie das Thema Standard-Funktionen in einer Amiga shared Library. Nur wenige Funktionen können problemlos verwendet werden; stdio, math, etc. gehören _nicht_ dazu. Zitat:Nix Gefahr, solche Automatismen greifen nicht (ohne weiteres) in einer shared library. [ - Antworten - Zitieren - Direktlink - ] |
21.02.2007, 16:56 Uhr whose Posts: 2156 Nutzer |
Zitat: Ähem, nicht böse sein, aber die Suche im Forum ergibt exakt einen Treffer bei "libnix AND libauto". Und genau diesen Thread habe ich z.B. nicht mitbekommen. Also nix x-mal... Zitat: Ok, und ich hatte verpennt, nochmal darauf hinzuweisen. Wie gesagt, mein Versäumnis. Zitat:Zitat:Nix Gefahr, solche Automatismen greifen nicht (ohne weiteres) in einer shared library. Kannst Du das evtl. mal näher erläutern? Also, wie die Automatismen funktionieren und aus welchen Gründen die in Amiga shared-Libraries nicht greifen? Auch auf die Gefahr hin, daß Du Dich da wiederholen mußt? Wenn ich da mal offen sprechen darf, genau diese Informationen sind nur sehr schwer (wenn überhaupt) zu finden, wenn man sich die einschlägigen Dokumentationen ansieht... Grüße -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233 [ - Antworten - Zitieren - Direktlink - ] |
21.02.2007, 20:26 Uhr gni Posts: 1106 Nutzer |
Zitat:Shared libraries verwenden die normalen Startupcodes nicht und genau diese sind für automatische Initialisierungen zuständig. Wie das im Einzelnen abläuft ist von System zu System und von (Standard-)Bibliothek zu Bibliothek verschieden. Selbst wenn Du die Initialisierung in Deiner shared library anstößt, hast Du immer noch das Problem, das die benutze Implementation der Standardfunktionen eventuell nur für single-thread Anwendungen ausgelegt ist. Und die Nutzung von abort() oder exit() für den Notfallabbruch sind eine weitere Verkomplizierung. Zitat:Im allgemeinen nennt man solche Initialisierungen Konstruktoren und Destruktoren ;) [ - Antworten - Zitieren - Direktlink - ] |
28.02.2007, 15:53 Uhr Der_Wanderer Posts: 1229 Nutzer |
Also ich habe jetzt alles hinbekommen ausser den Refrenzen auf pow, floor, exp, log usw. Ein -lm hilft komischerweise hier nicht beim linken. Wo bekomme ich diese Funktionen her ? -- Thilo Köhler, Author von: HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
28.02.2007, 17:08 Uhr Holger Posts: 8116 Nutzer |
Zitat: Das hängt u.U. von den verwendeten Prozessoroptionen ab. Aber prinzipiell schon von m. Poste doch mal die komplette Befehlszeile. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
28.02.2007, 17:40 Uhr Der_Wanderer Posts: 1229 Nutzer |
So kompiliere ich alle beteiligten c Dateien: gcc -DDUMB_DECLARE_DECPECIATED -IWork:Sourcecodes/c_dumb/dumb/include -noixemul -m68040 -nostartfiles -c #?.c dumb/src/core/#?.c dumb/src/it/#?.c dumb/src/helpers/#?.c Dann bekomme ich ein haufen .o Dateien im aktuellen Verzeichnis, und linke sie so: gcc -noixemul -nostartfiles -o dumb.library #?.o Ob ich da noch "-lm" oder "-lamiga" angebe spielt keine Rolle. Der Output sieht so aus: (die exit etc. bekomme ich in den Griff, aber die mathematischen Funktionen braucht man) 15.Work:Sourcecodes/c_dumb> gcc -noixemul -nostartfiles -lm -lamiga -o dumb.library #?.o clickrem.o(.text+0x1f4): undefined reference to 'pow' clickrem.o(.text+0x21a): undefined reference to 'floor' itread.o(.text+0x11b2): undefined reference to 'exit' itrender.o(.text+0x8a6): undefined reference to 'pow' itrender.o(.text+0x8f6): undefined reference to 'exp' itrender.o(.text+0x1a32): undefined reference to 'pow' itrender.o(.text+0x1a96): undefined reference to 'pow' itrender.o(.text+0x5848): undefined reference to 'pow' itrender.o(.text+0x58d2): undefined reference to 'pow' itrender.o(.text+0x59b2): undefined reference to 'pow' itrender.o(.text+0x6bc4): more undefined references to 'pow' follow readmod.o(.text+0x278): undefined reference to 'log' readmod.o(.text+0x294): undefined reference to 'log' readmod.o(.text+0x2c0): undefined reference to 'floor' readmod.o(.text+0x48e): undefined reference to 'pow' readxm.o(.text+0xb7c): undefined reference to 'pow' readxm.o(.text+0xbac): undefined reference to 'pow' resample.o(.text+0x4d0): undefined reference to 'floor' resample.o(.text+0x4466): undefined reference to 'floor' resample.o(.text+0x4960): undefined reference to 'floor' resample.o(.text+0x49b4): undefined reference to 'floor' resample.o(.text+0x97ec): undefined reference to 'floor' resample.o(.text+0x9840): more undefined references to 'floor' follow /gg/lib/libnix/libnix.a(__stdio.o)(.text+0x40): undefined reference to 'exit' /gg/lib/libnix/libnix.a(abort.o)(.text+0x38): undefined reference to 'exit' /gg/lib/libnix/libnix.a(raise.o)(.text+0x82): undefined reference to 'exit' /gg/lib/libnix/libnix.a(open.o)(.text+0x26c): undefined reference to '_WBenchMsg' /gg/lib/libnix/libnix.a(open.o)(.text+0x234): undefined reference to 'exit' -- Thilo Köhler, Author von: HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
28.02.2007, 20:04 Uhr Holger Posts: 8116 Nutzer |
Zitat:Der Unterschied zwischen link-Bibliotheken und einfachen object-files besteht darin, dass nur die Objekte verlinkt werden, die benötigte Symbole enthalten. Deshalb muss der Linker zuerst die object-files mit den Referenzen sehen, bevor er dann aus den Bibliotheken die benötigten Objekte dazulinken kann. Also: gcc -noixemul -nostartfiles -o dumb.library #?.o -lm -lamiga Aber die Bibliothek wird weiterhin nicht funktionieren, solange Du stdio benutzt. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
01.03.2007, 12:50 Uhr Der_Wanderer Posts: 1229 Nutzer |
@Holger Tatsächlich, es funktioniert ! Super danke! Jetzt muss ich nur noch die stdio Sachen raus killen. -- Thilo Köhler, Author von: HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
01.03.2007, 14:18 Uhr Der_Wanderer Posts: 1229 Nutzer |
Ok, ein Problem habe ich noch. Die folgenden Linker Errors bekomme ich nicht raus. Ich habe nirgends mehr stdio.h eingebunden, und alle fopen, fprintf, fclose etc. gemapped. Trotzdem bekomme ich hier noch einige Funktionen, aber der Linker sagt mir nicht, in welcher Datei ich genau darauf referenziere. 11.Work:Sourcecodes/c_dumb> gcc -noixemul -nostartfiles -o dumb.library #?.o -lm -lamiga /gg/lib/libnix/libnix.a(__stdio.o)(.text+0x40): undefined reference to 'exit' /gg/lib/libnix/libnix.a(open.o)(.text+0x26c): undefined reference to '_WBenchMsg' /gg/lib/libnix/libnix.a(open.o)(.text+0x234): undefined reference to 'exit' /gg/lib/libnix/libnix.a(raise.o)(.text+0x82): undefined reference to 'exit' collect2: ld returned 1 exit status -- Thilo Köhler, Author von: HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
01.03.2007, 14:55 Uhr gni Posts: 1106 Nutzer |
Zitat:Dann ist doch nicht alles raus ;-) Zitat:Gib beim Linken -Wl,-t mit an. Da sollte dann ersichtlich werden, woher die Referenzen stammen. Ansonsten kannst Du mit "nm -u *.o" alle undefinierten Symbole ermitteln. Warum linkst Du eigentlich explizit gehen amiga.lib? Das sollte unnötig sein. [ - Antworten - Zitieren - Direktlink - ] |
01.03.2007, 16:05 Uhr Der_Wanderer Posts: 1229 Nutzer |
Ok, hab noch ein paar Funktionen gefunden. Jetzt compiliert alles brav und lässt sich auch linken. Das resultat lässt sich allerdings nicht mit OpenLibrary öffnen. Gibt es noch was zu beachten ? z.B. die Reihenfolge beim Linken ? Woher weiss der GCC eigentlich, was mein Startcode von der Library ist ? Bei meiner Testlib gibts nur 2 .o files, daher scheint das wohl zu klappen. -- Thilo Köhler, Author von: HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
01.03.2007, 19:54 Uhr Der_Wanderer Posts: 1229 Nutzer |
Ok, es liegt tatächlich an der Reihenfolge des Linkens. Wenn ich meine Libinit.c (romtag etc.) als erstes dran linke, bekomme ich eine Shared Library die ich auch öffnen kann. Jetzt muss das ganze Biest nur noch funktionieren ... Wenn ich es getested habe lasse ich es euch wissen. Dann gibts einen tollen MOD player für alle Plattformen. (d.h. TKPlayer kann dann auch diverse MOD Formate). -- Thilo Köhler, Author von: HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
02.03.2007, 16:57 Uhr Der_Wanderer Posts: 1229 Nutzer |
Ok, jetzt kann ich die Lib zwar erstellen, aber es crashed schon in der ersten Funktion die ich aufrufe. Gibt es denn ausser der stdio noch weitere restriktionen, was eine Amiga Shared library betrifft ? Ich habe noch einige malloc and reallocs drin. Der Linker findet das aber ok. -- Thilo Köhler, Author von: HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
02.03.2007, 18:47 Uhr Georg Posts: 107 Nutzer |
@Der_Wanderer: Was malloc + co. betrifft, am besten diese in einem .c file reimplementieren, dann werden beim Linken diese genommen und nicht jene von der clib. Und du brauchst im orig. Source nicht überall malloc + co. durch anderen Code ersetzen. Z. B.: code:void *malloc(size_t size) { return AllocVec(size, MEMF_ANY); } void free(void *memory) { FreeVec(memory); } usw. [ - Antworten - Zitieren - Direktlink - ] |
02.03.2007, 18:55 Uhr Der_Wanderer Posts: 1229 Nutzer |
@Georg Ja, so habe ich das auch schon gemacht. Bringt leider nichts. Darf ich wirklich keine malloc benutzen ? Probleme gibts bei Realloc, weil man dazu die alte Größe wissen muss. Nagut, dann werde ich mich mal dransetzen und wirklich alle mit der Amiga API ersetzen. (per #define natürlich) -- Thilo Köhler, Author von: HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
1 -2- | [ - Beitrag schreiben - ] |
amiga-news.de Forum > Programmierung > Anfängerfrage: Wie linke ich eine .a Datei ? | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |