amiga-news 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

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

20.02.2007, 20:46 Uhr

Holger
Posts: 8090
Nutzer
Zitat:
Original von whose:
Da kann Dir aber "-lauto" evtl. weiterhelfen, wenn Du die dos.library nicht von Hand öffnen magst.


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: 8090
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:
Original von Holger:
Zitat:
Original von whose:
Da kann Dir aber "-lauto" evtl. weiterhelfen, wenn Du die dos.library nicht von Hand öffnen magst.


AAArgh!!
Was soll denn -lauto helfen, wenn man es mit Libraries zusammenlinkt?!
Einmal den freien Fall genießen?


Ä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

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

21.02.2007, 16:02 Uhr

gni
Posts: 1106
Nutzer
Zitat:
whose:
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?

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:
Das ich auf die Gefahr dieser Lösung bei Amiga-Shared-Libs nicht eingegangen bin, war aber mein Versäumnis. Verzeihung.
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:
Original von gni:
Zitat:
whose:
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?

Wie oft muß noch wiederholt werden, das -lauto bei libnix (-noixemul) _nicht_ verwendet werden muß!? Das wurde bereits x-mal durchgekaut.

Ä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:
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.

Ok, und ich hatte verpennt, nochmal darauf hinzuweisen. Wie gesagt, mein Versäumnis.

Zitat:
Zitat:
Das ich auf die Gefahr dieser Lösung bei Amiga-Shared-Libs nicht eingegangen bin, war aber mein Versäumnis. Verzeihung.
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

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

21.02.2007, 20:26 Uhr

gni
Posts: 1106
Nutzer
Zitat:
whose:
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?

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:
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...
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: 8090
Nutzer
Zitat:
Original von Der_Wanderer:
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 ?


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: 8090
Nutzer
Zitat:
Original von Der_Wanderer:
gcc -noixemul -nostartfiles -lm -lamiga -o dumb.library #?.o

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:
Der_Wanderer:
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.

Dann ist doch nicht alles raus ;-)
Zitat:
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

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-2022 by amiga-news.de - alle Rechte vorbehalten.
.