amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Programmierung > x86 native Amiga Shared Libraries unter Amithlon [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- 2 [ - Beitrag schreiben - ]

18.04.2006, 11:05 Uhr

bubblebobble
Posts: 707
Nutzer
Hallo Alle!

Hat jemand von euch schon mal eine Amiga Shared Library for Amithlon native kompiliert?
Ich versuche das gerade mit einigen DSP Effekten von HD-Rec. Das Problem was ich habe ist, dass ich die 68K Register nicht abfragen kann, um an die Parameter der Funktionen zu kommen.
Hat jemand ein Mini-Beispiel wie man das macht, oder weiss wo es Doku dazu gibt ?
Ich habe bereits ein Grundgerüst für eine 68K Library, und das funtkioniert auch mit dem 68K GCC. Aber einfach durch den x86 GCC (für Amtihlon) jagen geht nicht, wegen der besagten Register.

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de



[ Dieser Beitrag wurde von bubblebobble am 18.04.2006 um 11:07 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

18.04.2006, 15:09 Uhr

VMC
Posts: 115
Nutzer
@bubblebobble:

also das beste Beispiel sind noch immer die AHI-Sourcen
von Martin Bloom! Er hat den Bigendian GCC Compiler für
Amithlon gebaut und der Unterschied von einem Device wie
bei AHI zu einer Library ist nicht sehr gross.

In der Praxis wurde dies auch bei FxPaint umgesetzt wo
es auch einen nativen Amithlon Teil der Software gibt in
welchem Grafik Effekte auf x86 berechnet werden.

Mit freundlichen Grüßen,

Harald Frank

[ - Antworten - Zitieren - Direktlink - ]

18.04.2006, 17:25 Uhr

bubblebobble
Posts: 707
Nutzer
Hallo Harald!

Ja, die AHI Sourcen habe ich durchgesehen, kann aber die entsprechende Stelle nicht finden. Vielleicht ist es einfacher als ich dachte, aber schlau werde ich daraus nicht.

Ich werde wohl mal Martin Blom direkt fragen.

Danke für den Hinweis.
--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de



[ Dieser Beitrag wurde von bubblebobble am 19.04.2006 um 10:17 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

19.04.2006, 09:10 Uhr

gni
Posts: 1106
Nutzer
Zitat:
bubblebobble:
Ja, die AHI Sourcen habe ich durchgesehen, kann aber die entsprechende Stelle nicht finden.

Bei AHI werden die Interface-Stubs für jedes Target per sfdc gebaut. Dieses Programm (ein Perl-Skript) weiss, was für jedes mögliche Target zu tun ist. Was Du suchst ist in Device/Makefile.in zu finden (gatestubs.h, gatestubs.c). Für Amithlon könnte der Aufruf so aussehen:
code:
sfdc --target=i686be-amithlon --mode=gatestubs --output gatestubs.c --gateprefix=gw --libprefix=_ --libarg=last --addvectors=device ../../ahisrc-6.0/Include/SFD/ahi_lib.sfd

Obs korrekt ist und/oder funktioniert, das kann ich nicht sagen.

[ - Antworten - Zitieren - Direktlink - ]

20.04.2006, 00:16 Uhr

bubblebobble
Posts: 707
Nutzer
Ok, ich hab das Perl Script im AROS Source gefunden.
So ungefähr habe ich nun eine Ahnung, wie es gehen könnte, aber ich bekomme das nicht zum laufen. Da müsste ich erst eine .sfd File schreiben und Perl installieren, und dann mit ganz viel Glück ...

Weiss denn niemand wie das geht ? Ich denke es ist nur eine kleine Modifikation des 68K Library Frameworks.
Die Register werden mit einem x86 ASM Befehl in eine Structure geschrieben, aus der man sie dann Auslesen kann.
Mir ist aber immer noch nicht klar, ob das für den Anwender der Lib oder den Lib Developer gedacht ist. Zu viele Files, , und zu viele Unbekannte... :(
--
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 - ]

21.04.2006, 00:54 Uhr

bubblebobble
Posts: 707
Nutzer
Ok, ich bin jetzt schon ein ganzes Stück weiter und habe es geschafft, die Amithlon Stubs zu implementieren.
Jetzt kompiliert alles friedlich durch bis zum Linker, da bekomme ich:

/gg/i686be-amithlon/bin/ld: cannot open -lamigastubs: No such file or directory
collect2: ld returned 1 exit status
make: *** [fx_c_reverb_pro.library] Error 1

Ich weiss, den Fehler hatte ich schon mal bei meinem "hello_world.c", aber leider keine Ahnung mehr wie ich dasgelöst habe.
Im Netz habe ich gefunden, man solle "gg-fix-includes" laufen lassen, dann würde die Datei erzeugt.
Allerdings finde ich nirgends "gg-fix-includes".

Hilfe! Ich komme hier einfach nicht weiter. (Ich hasse GCC, und GCC hasst mich!)

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

21.04.2006, 08:57 Uhr

gni
Posts: 1106
Nutzer
Zitat:
bubblebobble:
/gg/i686be-amithlon/bin/ld: cannot open -lamigastubs: No such file or directory

Da scheint dann was zu fehlen oder die Bibliothek heisst jetzt anders. Versuch mal beim Linken mit -nostdlib zu arbeiten und alle benötigten Bibliotheken mit -l<name> selber anzugeben (wie die heissen, mußt Du selbst rausfinden). Oder Du erzeugst eine dummy libamigastubs.a, die Du dann entweder global installierst oder bei Deinem Projekt (dann mußt Du beim Linken -L. angeben). Oder Du editierst die specs Datei (wo die liegt sagt Dir "gcc -v")

[ - Antworten - Zitieren - Direktlink - ]

21.04.2006, 09:22 Uhr

Kaesebroetchen
Posts: 643
Nutzer
Zitat:
Original von bubblebobble:
/gg/i686be-amithlon/bin/ld: cannot open -lamigastubs: No such file or directory


Den gleichen Fehler hatte ich auch in einem CrossCompiler.
Nachdem ich auf anraten von gni, das -lamigastubs einfach aus der SPECS datei gelöscht habe, lief alles.

Ist das was du da benutzt, eigentlich ein CrossCompiler ?
Ich hätte noch Interesse an einem Cygwin CrossCompiler für Amithlon.
Wäre doch eine ganz nette Ergänzung für AmiDevCpp.
--
http://amidevcpp.amiga-world.de/

[ - Antworten - Zitieren - Direktlink - ]

21.04.2006, 10:14 Uhr

bubblebobble
Posts: 707
Nutzer
Ich benutze den GCC Crosscompiler von Martin Blom.

http://www.lysator.liu.se/~lcs/files/gg-cross/

Den gibt es wenn ich es richtig kapiert habe für Linux und 68k Amiga, und kompiliert Binaries für Amithlon x86 naive.

Die Installation ist allerdings der blanke Horror. Aber ein hello world habe ich damit geschafft, und konnte es auch ausführen.

Meine Libraries kompilieren nun Dank der Hilfe von Gni auch.

Nur der Linker will nicht. Ich weiss nicht ob das ein größeres Problem ist oder nicht.

>> Wäre doch eine ganz nette Ergänzung für AmiDevCpp
Ja klar, wäre super.

Was ist denn die SPECS Datei, und wo kann ich sie finden ?
(sorry, wenn das eine blöde Frage sein sollte)

Ich gebe diese Option nirgends an in meinem Makefile.

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

21.04.2006, 10:45 Uhr

Kaesebroetchen
Posts: 643
Nutzer
@bubblebobble:
Bei mir ist die in diesem Pfad (für m68k):

C:\CrossCompiler\AmiDevCpp\usr\local\amiga\lib\gcc-lib\m68k-amigaos\2.95.3

und hat folgenden Inhalt:

code:
*asm:
 %{m68000:-mc68010} %{mc68000:-mc68010} %{m68020:-mc68020} %{mc68020:-mc68020} %{m68030:-mc68030} %{m68040:-mc68040} %{m68060:-mc68060} %{m68020-40:-mc68020} %{m68020-60:-mc68020} %{!mc68000:%{!m68000:%{!mc68020:%{!m68020:%{!m68030:%{!m68040:%{!m68060:%{!m68020-40:%{!m68020-60:-mc68010}}}}}}}}} %{msmall-code:-sc}

*asm_final:


*cpp:
%{m68881:-D__HAVE_68881__} %{!ansi:%{m68020:-Dmc68020} %{mc68020:-Dmc68020} %{m68020-40:-Dmc68020} %{m68020-60:-Dmc68020} %{m68030:-Dmc68030} %{m68040:-Dmc68040} %{m68060:-Dmc68060} %{!noixemul:-Dixemul} %{noixemul:-Dlibnix}} %{m68020:-D__mc68020__ -D__mc68020} %{mc68020:-D__mc68020__ -D__mc68020} %{m68020-40:-D__mc68020__ -D__mc68020} %{m68020-60:-D__mc68020__ -D__mc68020} %{m68030:-D__mc68030__ -D__mc68030} %{m68040:-D__mc68040__ -D__mc68040} %{m68060:-D__mc68060__ -D__mc68060} %{!noixemul:-D__ixemul__ -D__ixemul} %{noixemul:-D__libnix__ -D__libnix} %{malways-restore-a4:-Derrno=(*ixemul_errno)} %{mrestore-a4:-Derrno=(*ixemul_errno)} 

*cc1:
%{resident:-fbaserel} %{resident32:-fbaserel32} %{msmall-code:-fno-function-cse} 

*cc1plus:


*endfile:
%{noixemul:-lstubs}

*link:
%{noixemul:-fl libnix} %{fbaserel:%{!resident:-m amiga_bss -fl libb}} %{resident:-m amiga_bss -amiga-datadata-reloc -fl libb} %{fbaserel32:%{!resident32:-m amiga_bss -fl libb32}} %{resident32:-m amiga_bss -amiga-datadata-reloc -fl libb32} %{g:-amiga-debug-hunk} %{m68020:-fl libm020} %{mc68020:-fl libm020} %{m68030:-fl libm020} %{m68040:-fl libm020} %{m68060:-fl libm020} %{m68020-40:-fl libm020} %{m68020-60:-fl libm020} %{m68881:-fl libm881} 

*lib:
%{!noixemul:%{!p:%{!pg:-lc -lamiga -lc}}%{p:-lc_p}%{pg:-lc_p}}%{noixemul:-lnixmain -lnix -lamiga %{mstackcheck:-lstack} %{mstackextend:-lstack}} 

*libgcc:
-lgcc

*startfile:
%{!noixemul:%{fbaserel:%{!resident:bcrt0.o%s}}%{resident:rcrt0.o%s}%{fbaserel32:%{!resident32:lcrt0.o%s}}%{resident32:scrt0.o%s}%{!resident:%{!fbaserel:%{!resident32:%{!fbaserel32:%{pg:gcrt0.o%s}%{!pg:%{p:mcrt0.o%s}%{!p:crt0.o%s}}}}}}}%{noixemul:%{resident:libnix/nrcrt0.o%s} %{!resident:%{fbaserel:libnix/nbcrt0.o%s}%{!fbaserel:libnix/ncrt0.o%s}}} 

*switches_need_spaces:


*signed_char:
%{funsigned-char:-D__CHAR_UNSIGNED__}

*predefines:
 -Dmc68000 -Damiga -Damigaos -DMCH_AMIGA -DAMIGA -D__chip=__attribute__((__chip__)) -D__saveds=__attribute__((__saveds__)) -D__interrupt=__attribute__((__interrupt__)) -D__stackext=__attribute__((__stackext__)) -D__regargs=__attribute__((__regparm__)) -D__stdargs=__attribute__((__stkparm__)) -D__aligned=__attribute__((__aligned__(4))) -Asystem(amigaos) -Acpu(m68k) -Amachine(m68k)

*cross_compile:
1

*version:
2.95.3

*multilib:
. ;

*multilib_defaults:


*multilib_extra:


*multilib_matches:


*linker:
collect2

*link_command:
%{!fsyntax-only:  %{!c:%{!M:%{!MM:%{!E:%{!S:%(linker) %l %X %{o*} %{A} %{d} %{e*} %{m} %{N} %{n} 			%{r} %{s} %{t} %{u*} %{x} %{z} %{Z}			%{!A:%{!nostdlib:%{!nostartfiles:%S}}}			%{static:} %{L*} %D %o			%{!nostdlib:%{!nodefaultlibs:%G %L %G}}			%{!A:%{!nostdlib:%{!nostartfiles:%E}}}			%{T*}			
 }}}}}}


Da werden je nach compiler oder linker Befehl automatisch parameter dazugepackt.
Unter anderem eben dieses -lamigastubs das ich hier allerdings entfernt habe.


--
http://amidevcpp.amiga-world.de/

[ - Antworten - Zitieren - Direktlink - ]

21.04.2006, 11:11 Uhr

gni
Posts: 1106
Nutzer
Zitat:
bubblebobble:
Was ist denn die SPECS Datei, und wo kann ich sie finden ?
(sorry, wenn das eine blöde Frage sein sollte)

Ich hatte doch geschrieben, wie Du die finden kannst: gcc -v sagt Dir wo sie ist.

Mit dieser Datei kann den GCC "konfigurieren". Das sollte man aber nur tun wenn man *wirklich* weis, was man tut.

[ - Antworten - Zitieren - Direktlink - ]

21.04.2006, 11:15 Uhr

gni
Posts: 1106
Nutzer
Zitat:
Kaesebroetchen:
C:\CrossCompiler\AmiDevCpp\usr\local\amiga\lib\gcc-lib\m68k-amigaos\2.95.3

Der Compiler ist für m68k-amigaos und deshalb:
Zitat:
Unter anderem eben dieses -lamigastubs das ich hier allerdings entfernt habe.
hat "-lamigastubs" da nichts zu suchen. Diese Bibliothek gibt es für m68k-amigaos nicht und hat es auch nie gegeben.

Was sagt gcc -dumpspecs? Ist diese Bibliothek da auch enthalten?

[ - Antworten - Zitieren - Direktlink - ]

21.04.2006, 11:45 Uhr

Kaesebroetchen
Posts: 643
Nutzer
@gni:
Werde ich bei gelegenheit mal gucken wenn es interessant für dich ist.
Mich persönlich interessieren die gcc interna nur insofern, das ich meine Sachen kompiliert kriege.

Die CrossCompiler die ich verwende kommen übrigens alle von Jocke Birging:

http://zerohero.se/

Und der hat zumindest die cygwin versionen eher lieblos zusammengebacken.
Für den Aros C++ support musste ich mir Dateien aus der Linux Version herauskopieren da die in der cygwin version schlicht fehlten.


--
http://amidevcpp.amiga-world.de/

[ - Antworten - Zitieren - Direktlink - ]

21.04.2006, 12:00 Uhr

bubblebobble
Posts: 707
Nutzer
Also ich habe die Datei "specs" gefunden und das "-lamigastubs" entfernt.
Ich muss dazu sagen, dass ich keinen Schimmer habe was ich da tue.

Nun kompilieren alle Libraries friedlich bis zu Ende. Aber sie laufen nicht :-/
Evtl. habe ich aber ein Bug im Quellcode, das muss ich noch prüfen.
Möglicherweise braucht man auch "run_elf PATCH" dazu, nur leider läuft bei mir weder run_elf 1.6 noch 1.8 stabil.

Ich denke aber, dass man -lamigastubs braucht, denn Martin Blom redet davon in der Readme. Dort steht, man müsse die notwendige Datei mit Hilfe von "gg-fix-includes --includes" generieren. Ich kann aber dieses Tool - oder was auch immer das ist - nirgends finden.

Warum kann man die Datei nicht einfach ins Archiv packen ?



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

21.04.2006, 14:00 Uhr

Kaesebroetchen
Posts: 643
Nutzer
@bubblebobble:
Also wenn die amigastubs wirklich benötigt würde, dann müsste doch eigentlich spätestens beim linken, sowas wie undefined symbol xyz kommen ?

Ich weiss nicht inwiefern man das auf Amithlon übertragen kann, aber hier ist von einer stubs.h die rede die man angeblich braucht:

http://www.zerohero.se/cross/os3.html

Inkludiere doch einfach mal probeweise <inline/stubs.h> und gucke was passiert.
--
http://amidevcpp.amiga-world.de/

[ - Antworten - Zitieren - Direktlink - ]

21.04.2006, 15:15 Uhr

gni
Posts: 1106
Nutzer
Zitat:
Kaesebroetchen:
Ich weiss nicht inwiefern man das auf Amithlon übertragen kann, aber hier ist von einer stubs.h die rede die man angeblich braucht:

Diese Datei wird bei m68k von inline/macros.h benötigt.
Zitat:
http://www.zerohero.se/cross/os3.html
Die Informationen dort sind teilweise mit Vorsicht zu geniessen :-/ Der Abschnitt zu macros.h ist komplett falsch...

[ - Antworten - Zitieren - Direktlink - ]

21.04.2006, 16:34 Uhr

Kaesebroetchen
Posts: 643
Nutzer
Zitat:
Original von bubblebobble:
Ich muss dazu sagen, dass ich keinen Schimmer habe was ich da tue.


Wer hat das heutzutage schon...

Zitat:
Nun kompilieren alle Libraries friedlich bis zu Ende. Aber sie laufen nicht :-/


Da fällt mir gerade was ein....
Du hast doch auch AfA_OS installiert, oder ?
Falls du die "Safer System" Option aktiviert hast, dann mach die mal weg und probiers noch mal.

Das hat mich kürzlich reichlich Nerven gekostet, da nicht mal ein Hallo Welt lief.
Es gab keinen Absturz, aber es tat sich halt nichts wenn ich das Programm gestartet habe.
Nachdem ich den Haken bei safer system weggemacht habe lief es dann sofort.

Muss ich nochmal gebau austesten und dann Bernd einen Bugreport schicken.

--
http://amidevcpp.amiga-world.de/

[ - Antworten - Zitieren - Direktlink - ]

22.04.2006, 02:06 Uhr

bubblebobble
Posts: 707
Nutzer
So, jetzt bin ich wieder ein Stückchen schlauer.

Die x86 Libraries kompilieren nun und starten, wenn ich "run_elf PATCH" benutze.
Aber run_elf meldet : Undefined Symbol "AllocMem"

Sieht also so aus, als ob er den Funktionsaufruf der exec von Allocmem nicht hinbekommt,
was verdächtig danach aussieht, dass der Linke um das amigastubs.a betrogen wurde.

Ich werde also wohl nicht darum herum kommen, diese Datei zu erzeugen und dem Linker mit -lamigastubs mitzuteilen.

=> Ich benötige das Tool gg-fix-includes. Hat das jemand ?

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

22.04.2006, 02:28 Uhr

bubblebobble
Posts: 707
Nutzer
Und wieder schlauer ...

Ich habe gg-fix-includes gefunden in "gg-fd2inlcude-1.38-2.tar.gz". Es handelt sich um ein Linux shell script, kann ich also nicht ausführen :-(

Jetzt werde ich Martin fragen müssen, ob er mir die File schickt.

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

22.04.2006, 06:27 Uhr

VMC
Posts: 115
Nutzer
Zitat:
Original von bubblebobble:
So, jetzt bin ich wieder ein Stückchen schlauer.

Die x86 Libraries kompilieren nun und starten, wenn ich "run_elf PATCH" benutze.
Aber run_elf meldet : Undefined Symbol "AllocMem"

Sieht also so aus, als ob er den Funktionsaufruf der exec von Allocmem nicht hinbekommt,
was verdächtig danach aussieht, dass der Linke um das amigastubs.a betrogen wurde.

Ich werde also wohl nicht darum herum kommen, diese Datei zu erzeugen und dem Linker mit -lamigastubs mitzuteilen.

=> Ich benötige das Tool gg-fix-includes. Hat das jemand ?


Hallo,

stimmt ich kann mich daran errinern das ich damals als
Martin seinen Compiler gemacht hatte ein ähnliches und
für mich auch nicht erklärbares Problem damit hatte die
benötigten stubs erstellt zu bekommen. Bei mir hatte
das gg-fix-includes selbst Probleme gemacht (unter Linux),
und ich konnte die benötigten stubs nicht erstellen!

Ich habe damals glaube ich die stubs header von einem
anderen Entwickler zugeschickt bekommen bei dem das
erstellen der stubs ohne Probleme durchgelaufen ist.
Solange man nur die üblichen System Funktionen benutzt
und keine eigenen Libs oder Devices verwendet stellt es
kein Problem dar, erst wenn du stubs für deine eigenen
Libs benötigst bist du wieder am Anfang des Problems :P

Zu dem "run_elf PATCH" denke ich ist klar das eine ELF
Datei nicht von alleine vom AmigaOS 3.1 System erkannt
wird und daher dieser System patch notwendig ist. Erst
recht bei einer Library oder einem Device, welches ja
auch von anderen m68k Programmen genutzt werden kann
die keinen Schimmer von x86/ELF haben :)

Btw, wenn dein big endian library Versuch klappt, denkst
du das du bereit wärst eine Version mit Sourcecode zu
Hilfezwecken für andere Entwickler bereit zu stellen die
ich zu den anderen Amithlon Entwicklersache dazu legen
darf? Es wäre für viele eine grosse Hilfe denke ich, da
sich die meisten gar nicht erst an sowas rantrauen!

Mit freundlichen Grüßen,

Harald Frank

[ - Antworten - Zitieren - Direktlink - ]

22.04.2006, 12:55 Uhr

bubblebobble
Posts: 707
Nutzer
@Harald

Klar, die Sourcen kann ich zur Verfügung stellen.
Was für andere Entwickler Sachen zu Amithlon gibt es denn ?
Ich hatte dich mal vor 1-2 Jahren gefragt, ob es sowas wie ein Amithlon SDK gibt, leider ohne jemals eine Antwort u bekommen. :-(

Wenn ich einemal die amigastubs.a habe, ist es einfach das für eine neue Library zu erstellen, ich denke dafür braucht man dieses Tool nicht, denn die amigastubs.a ist ja eine Textdatei.

Genauso habe ich das bei der gatestubs gemacht, wo man vom x86 die Parameter für die Library holt. Gni hat mir die stubs für AHI generiert, und ich habe mir das angeschaut und für die eigenen Lib umgebaut.

- Also, wenn jemand dieses gg-fix-includes laufen lassen könnte, wäre super. Ich glaube manbraucht Linux dazu und die x86 GCC installation für Amithlon.

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

23.04.2006, 17:57 Uhr

bubblebobble
Posts: 707
Nutzer
So, jetzt kann ich die Libraries kompilieren, und hinten kommt eine .library raus.

Allerdings sagt run_elf "Undefined Symbol pow" wenn ich die Library öffnen will.
Klar, die mathematische Funktion pow() benutze ich in der Library,
aber warum funtkioniert das nicht ?
Habe ich noch was vergessen einzubinden ?
Die amigastubs.a habe ich jetz drin und kompiliere mit "-lamigastubs".


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

23.04.2006, 19:16 Uhr

Holger
Posts: 8093
Nutzer
Zitat:
Original von bubblebobble:
Klar, die mathematische Funktion pow() benutze ich in der Library,
aber warum funtkioniert das nicht ?
Habe ich noch was vergessen einzubinden ?

math.h?

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

23.04.2006, 20:26 Uhr

thomas
Posts: 7680
Nutzer

-lm ?

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

23.04.2006, 23:36 Uhr

bubblebobble
Posts: 707
Nutzer
math.h habe ich natürlich eingebunden, sonst würde es ja erst gar nicht kompilieren oder ein Waring erzeugen.

"-lm" habe ich als linker option drin. Ist das ok ?
Ich meine, die 68k libs werden auch korrekt erzeugt, nur die x86 libs wollen nicht laufen.

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

24.04.2006, 18:14 Uhr

Holger
Posts: 8093
Nutzer
Zitat:
Original von bubblebobble:
math.h habe ich natürlich eingebunden, sonst würde es ja erst gar nicht kompilieren oder ein Waring erzeugen.

Aber wir reden immer noch von C, oder? ;)
Zitat:
"-lm" habe ich als linker option drin. Ist das ok ?
Ich meine, die 68k libs werden auch korrekt erzeugt, nur die x86 libs wollen nicht laufen.

Theorie und Praxis der Plattformunabhängigkeit von C. Wenn z.B. für Dein 68k-Target die Funktion als Prepräzessor, bzw. Assemblermakro implementiert wurde, fallen bestimmte Fehler bzgl. includes oder link-Optionen gar nicht auf.

Normalerweise sollte es aber mit #include <math.h> und -lm auch funktionieren. Aber ob cross-compiling für Amithlon noch als normal durchgeht ?(

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

24.04.2006, 19:02 Uhr

bubblebobble
Posts: 707
Nutzer
Ja, wir reden den ganzen Thread über C ;-)

Was bedeutet denn -lm ?

Was macht den C genau wenn ich z.B. "sin()" aufrufe ?
Wird dann die mathiee<blabla>.library geöffnet oder
macht das C intern irgenwie?


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

24.04.2006, 19:44 Uhr

Holger
Posts: 8093
Nutzer
Zitat:
Original von bubblebobble:
Was bedeutet denn -lm ?

"linke das Programm mit der Bibliothek m", typischerweise wird nach der entspechenden Bibliothek libm.so bzw. libm.a gesucht, aber das ist im Prinzip schon plattform/compilerspezifisch.
Zitat:
Was macht den C genau wenn ich z.B. "sin()" aufrufe ?
Wird dann die mathiee<blabla>.library geöffnet oder
macht das C intern irgenwie?

Es berechnet den Sinus des Funktionsarguments ;)

Im Ernst, wie das umgesetzt wird, ist compiler/ plattform/ prozessor- spezifisch. Selbst auf dem 68k-Amiga kann das unterschiedliches bewirken, je nach dem für welchen Prozessor (mit FPU oder ohne) Du übersetzt.

Das kann einen Aufruf einer Library-Funktion zur Folge haben, es kann aber genausogut in einem einzigen FPU-Befehl resultieren.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

24.04.2006, 20:01 Uhr

bubblebobble
Posts: 707
Nutzer
Heisst die Library tatsächlich "libm.a" ?

Also bei mir steht "-lm" als option für den Linker.

Dann beudetet also "-lamigastubs", dass er nach "libamigastubs.a"
sucht ?

Ich weiss auch nicht, ich komme hier einfach nicht weiter.
Normalerweise würder der Linker doch meckern, wenn er die Datei nicht findet. Und wenn ich nicht mit -lm linke, aber es wird benötigt, dann würde der Linker doch auch meckern, oder?

Meine x86 Libraries compilieren aber und linken ohne Warning oder Error.
Erst "run_elf" meckert, dass sin() oder pow() nicht definiert wären.
Wundert mich eigentlich, was zum #?! geht das "run_elf" an ?

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

24.04.2006, 20:21 Uhr

Holger
Posts: 8093
Nutzer
Zitat:
Original von bubblebobble:
Heisst die Library tatsächlich "libm.a" ?

Also bei mir steht "-lm" als option für den Linker.

Dann beudetet also "-lamigastubs", dass er nach "libamigastubs.a"
sucht ?

Ja, genau das heißt es.
Zitat:
Ich weiss auch nicht, ich komme hier einfach nicht weiter.
Normalerweise würder der Linker doch meckern, wenn er die Datei nicht findet. Und wenn ich nicht mit -lm linke, aber es wird benötigt, dann würde der Linker doch auch meckern, oder?

1. Ja, er meckert, wenn er sie nicht findet. Hat er ja im Falle von amigastubs schon mal gemacht.
2. Kommt drauf an. Der Linker weiß nicht, ob Du eine bestimmte Bibliothek benötigst. Er weiß allenfalls, daß es "unresolved symbols" gibt.
Zitat:
Meine x86 Libraries compilieren aber und linken ohne Warning oder Error.
Erst "run_elf" meckert, dass sin() oder pow() nicht definiert wären.
Wundert mich eigentlich, was zum #?! geht das "run_elf" an ?

ELF kann sowohl link-objekt, als auch ausführbare Dateien repräsentieren. Und unter Linux, auf dem Amithlon basiert, kann man dynamisch linken, daß heißt, die betreffende Bibliothek wird erst zum Startzeitpunkt gelinkt, und muß somit nur einmal im Speicher liegen, wenn mehrere Programme sie benutzen.

Das ist anders als beim Amiga, wo dynamische Bibliotheken völlig anders als Linker-Objekte aufgebaut sind.

Aber wenn mich meine Erinnerung nicht trügt, sollte auch beim dynamischen Linken der Linker beim Erzeugen der Anwendung überprüfen, ob die Symbole mit den verwendeten Bibliotheken aufgelöst werden können.

Das heißt, hier besteht eine Diskrepanz zwischen dem, was der Linker beim Erzeugen der Anwendung und was run-elf beim Laden sieht.

Möglicherweise sollte es auch gar nicht dynamisch sein (und funktioniert vielleicht mit run_elf gar nicht)

Wenn in Deiner Linker-Befehlszeile ein -dynamic steht, entferne es, wenn dort keins steht, ist es vielleicht ein default, den man mit -static überstimmen kann.

Aber das (der letzte Teil meines Postings) ist zugegebenermaßen schon über meinem Horizont, damit habe ich vor ewigen Zeiten mal zu tun gehabt, und das auch nicht so intensiv. Vielleicht weiß es jemand anders besser...

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]


-1- 2 [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > x86 native Amiga Shared Libraries unter Amithlon [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2022 by amiga-news.de - alle Rechte vorbehalten.
.