Zitat:

---

bubblebobble:
Möglicherweise brauchen auch manche Datatypes CGX, wenn du mit 24bit Bildern hantierst.

---

Zitat:

---

Flipflop:
Folgendes wird verwendet...

---

Zitat:

---

Flipflop:
Jemand eine Idee? Verzweifle schon fast...

---

Zitat:

---

Holger:
Wenn configure in der Lage wäre, Dich einfach danach zu fragen, wäre es vollkommen unnötig, irgendetwas für die build-plattform zu übersetzen.

---

Zitat:

---

DariusBrewka:

Zitat:

---

Der Compiler des Buildsystems kann logischerweise nicht benutzt werden um etwas über die Zielplatform herauszufinden. Das sollte einleuchtend sein.

---

Es wird in speziellen Fällen wohl so, aber Festgeschrieben ist das nicht und schon garnicht einleuchtend.

---

Zitat:

---

Holger:
long ist beim Amiga 4 bytes?

---

Zitat:

---

DariusBrewka:
Ich weiß jetzt nicht wo das Problem sein soll, aber warum soll man unter Linux mit einem Linux Compiler nicht herausfinden könne, ob AROS nun Beispielweise einen Growing stack pointer hat oder nicht? oder wie die Datenfeldlänge bestimmter Datentypen unter AROS sind. Für mich allsamt keine Argumente die hinderlich daran sind.

---

Zitat:

---

DariusBrewka:

code:

---

checking for growing stack pointer... configure: error: cannot run test programm while cross compiling

---

---

Zitat:

---

Uwe:
Ich habe 2.1 installiert gehabt.

---

Zitat:

---

Version 1.2 ist immer bei den gcc-Paketen dabei.

---

Zitat:

---

>2.0 gibt's auf der libnix-Homepage (bei Sourceforge.net).

---

Zitat:

---

Holger:

Zitat:

---

Man nehme bzero/memset

---

Müssen die nicht auch innerhalb von libnix implementiert werden?

---

Zitat:

---

Vielleicht sollte man, wenn man schon dabei ist, da auch mal einen kritischen Blick drauf werfen...

---

Zitat:

---

Aber evtl. delegieren die auch nur an eine AOS-Funktion.

---

Zitat:

---

Original von Holger:
Aber bei den meisten Prozessoren ist die Verwendung zweier Variablen, die beide in jedem Durchlauf verändert werden, aufwändiger als der Unterschied zwischen einem Test auf 0 und einem Vergleich. Somit ist folgendes besser:

for(b=a+l; a!=b; a++) *a=0;

---

Zitat:

---

Dietmar:
Warum nicht:

code:

---

i = l;
while (i)
    a[--i] = 0;

---

---

code:

---

for(;l!=0;l-=sizeof(size_t))
 *a++ = 0;

---

Zitat:

---

bubblebobble:

---

Zitat:

---

i686be-amithlon-gcc -noixemul -c -o fxlib_init.o fxlib_init.c

---

Zitat:

---

i686be-amithlon-gcc -noixemul -nostartfiles -r -o mylib.library fxlib_init.o mylib.o -lm utils_debug.o utils_string.o

---

Zitat:

---

i686be-amithlon-gcc

---

Zitat:

---

bubblebobble:
Gemäß der Readme muss man die Amithlon Binaries mit "-r" linken, steht sogar dabei "... like in the good old powerup days." oder so ähnlich.

---

Zitat:

---

Und was heisst das jetzt für mich ? Wie bekomme ich dann die mathematischen Funktionen zum laufen, oder evtl. noch andere Dinge die ich benutze ?

---

Zitat:

---

Was ist z.B. wenn ich OS Libraries benutze (z.B. graphics.library), wo ich per OpenLibrary() rankomme, das betrifft es aber nicht, oder ?

---

Zitat:

---

Holger:
Statt einer for-Schleife benutzt man eine do-while Schleife, warum? Weil man eine Vortest einsparen wollte (was dann bei Uwe für den Absturz gesorgt hat)?

---

Zitat:

---

bubblebobble:
run_elf beschwert sich über alle Funktionen, die dazu gelinkt wurden,
wie pow() sin() etc.

---

Zitat:

---

Holger:
Wow, ja das ist C-Code der alte Schule.

---

Zitat:

---

Immer nach dem Motto "je krypischer es aussieht, desto höher muß wohl die Performance sein".

---

Zitat:

---

Tja, irgendwann fällt so ein Mist jemanden auf die Füße, und wie so oft, jemanden, der nix dafür kann.

---

Zitat:

---

Uwe:
StormC liefert bei malloc(0) einen gültigen Zeiger. gcc/ixemul stürzt bei einem malloc(0) ab, da laut ixemul-Sourcen direkt auf AllocMem(0, ...) abgebildet wird.

---

Zitat:

---

libnix funktioniert auch nicht (fehlende Funktionen, weitere Inkompatibilitäten)

---

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:

---

Zitat:

---

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

---

Zitat:

---

o.eschi:
Aber wo zum Geier liegt überhaupt das usbpalm.device???

---

Zitat:

---

Habe ich gerade einen Denkfehler???

---

Zitat:

---

Kaesebroetchen:
C:CrossCompilerAmiDevCppusrlocalamigalibgcc-libm68k-amigaos2.95.3

---

Zitat:

---

Unter anderem eben dieses -lamigastubs das ich hier allerdings entfernt habe.

---

Zitat:

---

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

---

Zitat:

---

Cego:
Läuft die wb mit hsmathlibs auch spürbar schneller?

---

Zitat:

---

bubblebobble:
/gg/i686be-amithlon/bin/ld: cannot open -lamigastubs: No such file or directory

---

Zitat:

---

bubblebobble:
Ja, die AHI Sourcen habe ich durchgesehen, kann aber die entsprechende Stelle nicht finden.

---

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

---

Zitat:

---

Pro2-2001:
Das Early-Startup-Menu sollte doch an und für sich gehen oder?

---

Zitat:

---

rbn:
Bei mir lief es ganz einfach noch nie. Und das seit 3.1.

---

Zitat:

---

rbn:
Lass von dem TNG besser die Finger. Das ist buggy und läuft nicht auf allen Konfigs, zumal es dir keine Zusatzoptionen bietet.

---

Zitat:

---

Pro2-2001:
Das Einschaltbild mit der Diskettenanimation sehe ich über den angeschlossenen 19" iiyama Monitor.

---

Zitat:

---

Ich kann zwar die Workbench 3.9 booten mit Picasso96 1024x768 aber sobald ich einen PAL Screen öffne kommt das Bild nur über den Amiga-Monitor-Ausgang.

---

Zitat:

---

Ich habe hier im Forum etwas gelesen über ein Picasso Programm wo man den Flickerfixer der PicassoIV einstellen kann.

---

Zitat:

---

Musicman:
es gibt ein Program was über die Workbench im Prefs die Daten vom FliFi verändern kann, ich glaube es hies PVS oder so ähnlich.

---