DEUTSCHE VERSION |
|
Links | | | Forums | | | Comments | | | Report news |
Chat | | | Polls | | | Newsticker | | | Archive |
amiga-news.de Forum > Search | [ - Search - New posts - Register - Login - ] |
|
||||||
gni
User
2013-01-08, 10:18 h [ - Direct link - ] |
topic: Gibt es ein Standard-#define für Amiga-Systeme?
Board: Programmierung Zitat:Ich denke mal, das der AmigOS-Port des GCC immer ein eingebautes #define für AMIGA haben wird, alleine um SAS/C kompatibel zu sein bzw. zu bleiben. Ein weiteres Kompatibilitätsdefine ist MCH_AMIGA, das stammt noch von Aztec-C. FWIW, die angesprochene GCC Portierung hat vor sehr langer Zeit ein anderes Symbol als neues Standardefine eingeführt: __amigaos__ - später wurde das dann für OS4 abgewandelt Ach ja das #define __amiga__ gibt es beim GCC auch. BTW, bitte die Unterstriche beachten! Die Symbole ohne Unterstriche sind nicht immer definiert! Zitat:IMHO ist der vorgeschlangene Ansatz keine gute Idee, da AMIGA hier u.U. einfach überdefiniert wird (edit: beim GCC hast Du es vorher entfernt . Sowas sollte immer unterbleiben. Also entweder vorher ein #undef oder vermutlich besser #ifndef AMIGA verwenden. Zitat:Hier würde ich defined (__amigaos__) ergänzen.code:#if defined (__amigaos4__) || defined(__MORPHOS__) || defined(__AROS__) Zitat:Laut Doku und config hat VBCC wirklich kein OS #define.code:#if defined(__VBCC__) && defined(__M68K__) #define AMIGA Zitat:Das kann komplett raus.code:#if defined(__GNUC__) && (defined(_M68000) || defined(__M68000) || defined(__mc68000)) #undef AMIGA #define AMIGA Im übrigen kennt der GCC "nur" mc68000 (mit doppelten Unterstrichen davor und dahinter bzw nur davor) und Varianten für mc680x0 mit x=2,3,4,6. Seit 4.3 gibt es auch x=1. Die M68000 Symbole sind von SAS/C bzw von VBCC. Zitat:Der SAS/C Test kann entfallen. Maxon und Dice kenn ich nicht (gut genug).code:#if defined(__SASC) || defined(__MAXON__) || defined(__DCC) #define AMIGA #endif |
|||||
gni
User
2012-02-10, 08:36 h [ - Direct link - ] |
topic: HTMLView, gcc und fread, komische Dinge passieren
Board: Programmierung Zitat:Das Beispiel aus den AmiNet-Archiven läßt sich ohne Anpassung an den GCC nicht übersetzen, da es für StormC geschrieben worden ist. Für C++ müßte es auch angepaßt werden. Von daher noch mal die Frage, ob Du ein kleines vollständiges Beispiel hast. Am besten wäre der Quellcode und das Präprozessorfile (.i für C bzw. .ii für C++, das erhält man mittels -save-temps). Damit könnte ich Dein Problem analysieren und mit verschiedensten GCC Versionen testen. Benutzt Du -DNO_INLINE_STDARG? |
|||||
gni
User
2012-02-08, 09:42 h [ - Direct link - ] |
topic: HTMLView, gcc und fread, komische Dinge passieren
Board: Programmierung Zitat: Hast Du mal ein kleines (aber vollständiges!) Beispiel mit dem sich das Problem nachvollziehen läßt? Ich baue zwar auch immer den C++ Compiler, nur verwende ich den so gut wie nie. Der Compiler wird meist nur benutzt um die libstdc++ des GCC zu bauen. |
|||||
gni
User
2012-02-06, 09:21 h [ - Direct link - ] |
topic: HTMLView, gcc und fread, komische Dinge passieren
Board: Programmierung Zitat:Wenn das mit C++ übersetzt werden soll, dann ist "extended asm" eine Möglichkeit. Für C++ sollte man jedoch auch über die Verwendung von HookEntry() aus der amiga.lib nachdenken. Zitat:Warum nicht was neueres als 2.95? Zitat:Die SAS/C-Schlüsselworte werden von GCC Versionen (die diese auch unterstützen) nicht wegdefiniert, sondern in die entsprechenden GCC-Attribute umgesetzt. So braucht man den Code halt nicht speziell an den GCC anpassen. Zitat:Ja, wenn man mit den entsprechenden Optionen übersetzt, dann haben diese Schlüsselwörter auch einen Effekt. Die Option für small-data lautet -fbaserel. Das muß sowohl beim Übersetzen als auch beim Linken angegeben werden. Zitat:GCC verwendet standardmäßig das große Datenmodell. SAS/C verwendet standardmäßig "small-data". |
|||||
gni
User
2011-01-03, 08:33 h [ - Direct link - ] |
topic: OS4 SDK mit SDL: Undefined references
Board: Programmierung Zitat:Ups, Du hast recht - tut mir leid. Da war der Satzbau für mich zu kompliziert .-) |
|||||
gni
User
2010-12-30, 14:17 h [ - Direct link - ] |
topic: OS4 SDK mit SDL: Undefined references
Board: Programmierung Zitat: Und bei Dir funktioniert Deine angegebene -l<...> Option? Wenn ja müßte die Bibliothek bei Dir "liblibSDL.a" heissen (beachte das doppelte lib!). Wenn die Datei jedoch nur "libSDL.a" heißt, dann ist -lSDL vollkommen richtig! |
|||||
gni
User
2010-07-08, 08:20 h [ - Direct link - ] |
topic: Der Stack gehört mir! (?)
Board: Programmierung Zitat:Warum nicht? |
|||||
gni
User
2010-07-08, 08:19 h [ - Direct link - ] |
topic: Der Stack gehört mir! (?)
Board: Programmierung Zitat: Entweder "move.l #MySP,a1" oder den Gartenzaun weglassen. |
|||||
gni
User
2010-05-26, 12:36 h [ - Direct link - ] |
topic: Stormwizard GUI Editor mit BlitzBasic oder lieber C (Anfänger) !??
Board: Programmierung Zitat:Kannst Du das bitte etwas genauer erläutern? |
|||||
gni
User
2010-05-24, 11:01 h [ - Direct link - ] |
topic: SDI-Makros und vbcc-m68k
Board: Programmierung Zitat:Schön das Du das Problem identifizieren konntest! Zitat:Stimmt, das "hier" hatte ich übersehen. Zitat:Dito. Dennoch solltest Du Dein (oder eben mein System nicht als repräsentativ ansehen. Zitat:Wenn es eine korrekten Weg gibt und man den auch kennt, dann sollte der auch benutzt werden. Alles andere fällt einem früher oder später (meist früher immer auf die Füße...Zitat:Ich weiß. Allerdings gibt es kein offizielles i686 Backend von 'vbcc', welches AROS unterstützt. Zitat:Da sich jetzt gezeigt hat, das die SDI-Header VBCC nicht korrekt unterstützen, sollte das nun behoben werden. Es wäre interessant zu wisse, ob __M68K__ schon immer das Architektur #define von VBCC war. Mein eigenes compiler.h testet auch __M68000 und ich glaube das das mal korrekt war, aber 100% sicher bin ich mir da auch nicht. Zitat:Kein Compiler erzählt irgendwas über sein Host-System, denn welchen Sinn sollte das haben? Alle #defines beziehen sich ausschließlich auf das Zielsystem.Zitat:Exakt das meinte ich. |
|||||
gni
User
2010-05-20, 17:56 h [ - Direct link - ] |
topic: SDI-Makros und vbcc-m68k
Board: Programmierung Zitat:Mysteriös. Werde ich bei Gelegenheit mal testen. Zitat:Und dann wird auch in den richtigen REG-Block gegangen?Zitat:Ja, mittels "#error" Ausgabe veranlasst, um zu sehen, ob der für 'vbcc' vorgesehene Block angesprungen wird. Zitat:Nein. Dann weißt Du nur, das es _nicht_ PPC ist. Du willst aber wissen ob es m68k ist und das testet Du bei VBCC mit __M68K__ (bei GCC wäre es __mc68000 und bei SAS/C ist es _M68000). Zitat:Wieso? Wenn ein Compiler das definiert, dann wird er schon für m68k Code erzeugen und genau das soll ja geprüft werden. Zitat:Du implizierst, das es 68k ist und diese Schlußfolgerung ist nicht zwangsläufig richtig. Zitat:SAS/C und GCC verwenden andere #defines (siehe oben). |
|||||
gni
User
2010-05-20, 08:40 h [ - Direct link - ] |
topic: SDI-Makros und vbcc-m68k
Board: Programmierung Zitat:Das angegebene SDI_compiler.h sieht aber korrekt aus. Hast Du geprüft, ob VBCC wirklich durch den __VBCC__ Block geht? Zitat:c code:#if (defined(__VBCC__) && !defined(__PPC__)) #undef REG #define REG(reg,arg) __reg(#reg) arg #endifc code:#if (defined(__VBCC__) && !defined(__PPC__)) || defined(_M68000) || defined(__M68000) || defined(__mc68000) !__PPC__ kann nicht richtig sein. Wenn dann "&& defined(__M68k__)". Ich hätte jetzt allerdings auch erwartet, das __M68000 immer definiert ist, laut .pdf ist das aber anscheinend nicht der Fall, müßte man prüfen. |
|||||
gni
User
2010-04-26, 08:12 h [ - Direct link - ] |
topic: MJPEG - AVIs unter OS3.9/WarpOS abspielen
Board: Amiga, AmigaOS 4 Zitat: Wo ist der Quellecode dieser Version? |
|||||
gni
User
2009-11-22, 19:27 h [ - Direct link - ] |
topic: gcc >3.4.x __asm("fpx") problem
Board: Programmierung Zitat:Bis einschließlich 4.2 genügt -m68040/-m68060 um FPU-Befehle zu generieren. -m68881 hat die unangenehme Nebenwirkung, daß math.h das math-68881.h include einbindet. Das kann gewollt sein oder eben nicht. Der Compiler selber erzeugt auch mit -m68881 nur FPU-Befehle die der Prozessor in HW hat. Zitat:Danke, dann wäre das also geklärt. Ich hatte zuerst in den Ausgaben die Fehlermeldung vermißt :-) Zitat:An den Pfaden liegt es nicht, was nicht heißt, das die IDE mit den Pfaden korrekt umgeht - das tut sie definitiv nicht. Standardincludepfade müßen _nie_ per -I angegeben werden, alles unter dem Installationsort des Compilers findet der Compiler selber. Wenn nicht ist die Installation fehlerhaft. |
|||||
gni
User
2009-11-22, 18:25 h [ - Direct link - ] |
topic: gcc >3.4.x __asm("fpx") problem
Board: Programmierung Zitat: Nimm Dein Beispiel, das gl.h Include, und laß die IDE weg. Compiliere das ganze auf der Kommandozeile: gcc -v -c foo.c bzw. g++ -v -c foo.c. Danach zusätzlich -m68881 bzw -m68040/-m68060 angeben. Die Ausgaben die dann kommen hier zeigen. Dein Beispiel funktioniert definitiv mit allen GCC <= 3.4. Neuere habe ich nicht getestet, aber da wird es keinen Unterschied geben. |
|||||
gni
User
2009-11-22, 14:19 h [ - Direct link - ] |
topic: gcc >3.4.x __asm("fpx") problem
Board: Programmierung Zitat: Nein, das kann es _nicht_ gewesen sein. Ich kann Deinen Schnipsel mit dem angegebenen gl.h nach Definition von APIENTRY und GLenum ohne weiteres auch mit dem C++ Compiler übersetzen. Der entscheidende Faktor ist die FPU-Einstellung: man braucht entweder -m68881 oder -m68040/-m68060 damit der Compiler auch die FPU-Register kennt. |
|||||
gni
User
2009-07-08, 10:56 h [ - Direct link - ] |
topic: debugging 68k app under os4?
Board: Programmierung Zitat:AFAICT, Resource V6 soll auf Grafikkarten laufen. V5 braucht einen nativen Screen _und_ ChipMem für seine Menues. Mit Flickerfixer (wie zum Beispiel in der PIV) ist V5 absolut benutzbar. monam sollte mit Grafikarten funktionieren, zumindest mein Uralt V2 kommt mit einem CGFX-Screen klar. Ansonsten versuchts mal mit BDebug aus dem Barfl-Paket. |
|||||
gni
User
2009-06-23, 11:27 h [ - Direct link - ] |
topic: OS3.x nativer GCC
Board: Programmierung Zitat:Das sind alles in reine GG-Erweiterungen, dh. in den offiziellen Quellen von binutils und GCC ist das Target m68k-amigaos nicht bekannt und damit fehlen alle diese Feature. Diese Erweiterungen werden durch Patches "nachgerüstet". Zitat:Äh, nein. Neuere Ports als 3.4.0 mit allen Erweiterungen sind nur nicht verfügbar gemacht worden. Unter anderem deshalb weil ich mit GCC4 nicht zufrieden bin. In einem Punkt hat(te) Bernd allerdings recht: für "moderne" C++ Quellen braucht es einen aktuellen GCC, unabhängig davon wie gut der erzeugte Code ist. Ich verwende den C++ Compiler jedoch schlichtweg nicht.Zitat:Also ohne Amiga-Features. Zitat:Schau auf der GCC Hompage ins Manual von neueren Versionen. Eine prinzipielle Änderung betrifft die Nutzung von gmp und mpfr. Die sind seit 4.3 zwingend zum Erstellen des GCC erforderlich. Zur Qualität dieser Versionen bezüglich Codegüte kann ich nichts konkretes sagen. Die vorigen GCC4 Versionen waren jedoch in meinen Tests nicht besser als GCC3, eher schlechter. Zitat:Ja und ja. FWIW, die binutils in adtools sind das Aktuellste was für AmigaOS/68k verfügbar ist. Eine "bessere" Version gibt es nicht, da fast alle späteren Änderungen der GG Version 2.9.1 dort eingepflegt worden sind. Das "fast" bezieht sich darauf, das ich in meiner 2.9.1 Version Backports für GAS und den Demangler aus den Trunk-binutils eingepflegt habe. Zitat:Prinzipiell richtig. m68k-amigaos als Target geht aber nur, wenn Du entweder Bernds Quellen verwendest oder selber dem configure der GCC Versionen m68k-anigaos als Target bekannt machst. |
|||||
gni
User
2009-06-22, 18:28 h [ - Direct link - ] |
topic: OS3.x nativer GCC
Board: Programmierung Zitat:Direkt unter 68k übersetze ich mittlerweile sehr selten. Dauert mir einfach zu lange Zitat:Dort wird eine der Versionen aus dem Alpha-Zweig verwendet. Zitat:OS4 wird komplett unterstützt. Die dortigen binutils haben auch vollständige m68k-Unterstützung, dh. alles was man für m68k-amigaos als Target braucht ist vorhanden. Zitat:Diesen Versionen fehlen alle speziellen Amiga-Features. Laut Bernd braucht man diese Dinge aber auch nicht. Darüber gibt es jedoch unterschiedliche Auffassungen Unproblematisch sind diese neuen GCC Versionen auch nicht [1,2]. FWIW, ich denke GCC 4.3/4.4 als Cross-Compiler ist gut "genug". Native willst Du nicht wirklich: unter FreeBSD (x86) sind die Compiler um die 5MB groß (gmp und mpfr sind statisch eingelinkt, so wie es bei einem nativen GCC für AmigaOS/68k auch sein würde). Ich habe auch nie probiert, wie aufwändig es wäre 4.3/4.4 zum laufen zu bekommen. 4.2 sollte gehen, aber bis auf ein triviales C "Hello world" habe ich nichts weiter übersetzt. Zitat:Gab es nie für GG. Zitat:Das diese Versionen im Alpha-Zweig zu finden sind, liegt nur daran, das es keine neueren GG-Snapshots gegeben hat. IMHO sind diese beiden Versionen ohne Probleme benutzbar, auch wenn sie mittlerweile ein Paar Jahre auf dem Buckel haben. Zitat:Ich habe nicht den blaßesten Schimmer wie so ein Verhalten entstehen könnte. Zitat:Der Compiler benötigt eine gewisse Umgebung, dh. Assigns und Verzeichnise + Dateien unterhalb dieser Assigns. Die braucht es immer, egal ob reines GG oder Cubic. Zitat:Mir reicht (meist) ein Cross-Compiler. Für neue(r)e GCC-Versionen sind echte m68ks schlicht nicht leistungsfähig genug. Und mit 128MB/256MB kommt man vermutlich auch nicht weit, vor allem bei C++. Zitat:adtools war/ist der Versuch Entwicklungswerkzeuge für verschiedene Spielarten von AmigaOS in einen Projekt zu bündeln. Nur die OS4 Unterstützung ist (halbwegs) vollständig, dh. binutils und GCC. Für m68k gibt es nur binutils. Die binutils enthalten auch Code für MorphOS, aber ob der funktioniert, weis ich nicht. Zu AROS kann ich gar nix sagen. devtools ist eines der vielen Projekte von Bernd Roesch. Es ist sein Versuch neuere GCC Versionen als 3.4 für AmigaOS/68k nutzbar zu machen. Diesen dort verfügbaren Versionen fehlen alle speziellen Amiga-Features wie baserel Modus, stackcheck bzw. stackextenion Modus, Registerargumente (nur C), etc. Bernd vertritt die Auffassung das das alles nur unnötiger Ballast ist, den niemand braucht. Für mich definiert sich ein Amiga-Compiler aber genau dadurch, das er diese Feature hat. Zitat:Weil es sehr schwierig ist, die Anpassungen von OS4 bzw AmigaOS/68k in die offiziellen Quellen zu bekommen. Zum einem muß jemand den Code später auch pflegen oder er wird wieder entfernt. Zum anderen erfordern die Amiga-Feature Änderungen an generischen Quellen und das ist ein echtes Hindernis. |
|||||
gni
User
2009-05-15, 09:00 h [ - Direct link - ] |
topic: GCC compiler error on new field creation
Board: Programmierung Zitat:Genau daran liegt es. Zumindest GCC 4(.3.2) mag das nicht. Zitat: Zum Übersetzen kann auch "gcc" verwendet werden, da das Frontend den passenden Compiler anhand des Suffixes der Quelldatei auswählt. Zum Linken sollte man aber besser "g++" benutzen, da dann automatisch an der richtigen Position gegen die libstdc++ (und eventuell libm) gelinkt wird. Das kann wichtig sein. [ Dieser Beitrag wurde von gni am 15.05.2009 um 09:01 Uhr geändert. ] |
|||||
gni
User
2009-03-25, 08:36 h [ - Direct link - ] |
topic: GoldED Studio AIX und SDL-Installation
Board: Programmierung Zitat: Der GCC hat "eingebaute" Pfade zu Includes und Libraries. Teilweise kommen solche Angaben auch aus dem "specs", zb. für newlib, clib2, etc. Zitat: Wenn es ein fest eingebauter Pfad ist, dann sucht der GCC dort von sich aus. Benutze beim Übersetzen die Option -v, dann zeigt Dir der GCC an welchen Stellen Includes gesucht werden. |
|||||
gni
User
2009-03-01, 12:44 h [ - Direct link - ] |
topic: S: beste Grafiklösung zum Anschluss eines Amiga 4000 D am TFT
Board: Kleinanzeigen (keine Auktionen!) Zitat: Mit einem passenden TFT geht bei der PIV auch 1280x1024 in 16Bit ohne die Karte zu "überfahren". |
|||||
gni
User
2009-02-19, 13:10 h [ - Direct link - ] |
topic: spezielles JPEG-Anzeigeprogramm gesucht
Board: Amiga, AmigaOS 4 Zitat: Manche JFIF-Datatypes können das. |
|||||
gni
User
2008-12-08, 09:12 h [ - Direct link - ] |
topic: localtime() gmtime() sas/c
Board: Programmierung Zitat: Du hast keine globale Umgebungsvariable TZ gesetzt, deshalb bekommst Du den SAS/C Defaultwert für _TZ. Das steht alles im Guide unter Zeitfunktionen/tzset. |
|||||
gni
User
2008-10-02, 21:13 h [ - Direct link - ] |
topic: AmiBlitz will nicht, welche alternative ist die Beste ?
Board: Programmierung Ich würde Dir vorschlagen, Du machst einen neuen Thread auf. Das Thema GCC ist hier off-topic. Ich weis, ich habe diese Abweichung angezettelt. Mea culpa. Meine letzte Antwort dazu hier. Mhm, warum nutzt niemand mehr usenet!? Zitat:Das hat nichts zu sagen. Zitat:Der Unterschied 68k/Coldfire ist gewaltig. Und nur weil eine Änderung vor 3 Wochen(!) gemacht wurde, bedeutet das nicht, das aktiv am m68k Port gearbeitet wird. Und wieviele Änderungen sind bei anderen Architekturen in den letzten drei Wochen vorgenommen worden? Zitat:Das hat nichts mit Parameterübergabe in Registern zu tun. Das müßte für globale Registervariablen sein. Zitat:Beim Konfigurieren CFLAGS angeben: CFLAGS= .../configure <args> und beim Bauen auch: make CFLAGS= bzw make CFLAGS="-O". Beim Konfigurieren kann man es vermutlich weglassen, aber ich geb es immer an. Redundanz hat noch nie geschadet Zitat:Wenn Du nicht an den CFLAGS rumgespielt hast, dann wird doch mit -g gebaut und dann kannst Du doch debuggen? Zitat:Da hast Du augenscheinlich ein Verständnisproblem. Weder MOS noch OS4 brauchen das. Auch bei AmigaOS/68k braucht man es nicht wirklich, da dort OS-Aufrufe mit einer existierenden GCC Erweiterung gemacht werden. Da jedoch SAS/C das unterstützt(e), mußte der Amiga-GCC Port das auch können ;-) Und ich benutze es gelegentlich auch, ist aber nur mit Obacht benutzbar. Zitat:Ohne Adaption der Patches an neue GCC Versionen geht es nicht. Punkt. Zitat:Nö muß man nicht. Zumindest nicht bei 4.2.x. Bei 4.3 mag das bereits anders aussehen. Zitat:Hast Du Dir mal überlegt wo bei 3.4.x der Parameter asmspec herkommt? |
|||||
gni
User
2008-10-02, 15:58 h [ - Direct link - ] |
topic: AmiBlitz will nicht, welche alternative ist die Beste ?
Board: Programmierung Zitat:Das Du 4.3.2 verwendet hast, hatte ich übersehen. FWIW, ich würde nicht mit 4.3 anfangen, auch wenn das die aktuelle GCC Version ist. Der Unterschied zu 3.4.0 ist einfach zu groß, zb. wurde in der Zwischenzeit der C-Parser ersetzt, Prologue und Epilogue werden jetzt per RTL gemacht, die Kommandozeilenparameter für m68k wurden geändert (IMO zum schlechteren), etc. Zitat:Wie geschrieben: 9min für configure+build bei 4.2.0. Das beinhaltet alles was gebraucht wird. Zitat:Zu cygwin und Linux kann ich nichts sagen, da ich beides nicht benutze. Ich arbeite mit FreeBSD. Zitat:Ich verwende nicht die standardmäßigen CFLAGS. Soviel Plattenplatz habe ich nicht zur Verfügung. Ich baue ohne -g. Zitat:Ein GCC ohne die Amiga-spezifischen Erweiterungen ist unbrauchbar und das oben genannte Feature ist eine reine Amiga-Erweiterung. Zitat:Da es nicht im GCC enthalten ist, scheint es wohl doch nicht notwendig zu sein? Zitat:m68k scheint ein Spezialfall zu sein. Auch nach größeren Änderungen am GCC-Kern hat der Port danach weiterhin funktioniert. Es gibt aber meines Wissens niemanden der aktiv an m68k entwickelt. Die letzten größeren Änderungen am m68k-Port sind durch ColdFire-Änderungen motiviert gewesen. |
|||||
gni
User
2008-10-02, 15:10 h [ - Direct link - ] |
topic: AmiBlitz will nicht, welche alternative ist die Beste ?
Board: Programmierung Zitat:Also für mich sieht es jetzt doch so aus, als ob sein System einen Fehler in AB3 zum Vorschein bringt. Eventuell wird ja bei ihm ein wichtiger Bereich des System "beschädigt", so das es zum Absturz kommt. Solche Fehler sind die schlimmsten, weil 99% ;-) sagen funktioniert und 1% hat Probleme... |
|||||
gni
User
2008-09-28, 20:28 h [ - Direct link - ] |
topic: AmiBlitz will nicht, welche alternative ist die Beste ?
Board: Programmierung Zitat:Ich nehme mal an es geht um den GCC 4.2.x? Unter welchem System wird übersetzt? Welche Sprachen werden gebaut? Bei mir dauert das Konfigurieren und einfaches Bauen von 4.2.0 mit C und C++ Compilern 9 Minuten auf einem "alten" Pentium-M 1.5GHz Laptop und langsamer Platte. Das ist zwar auch nicht wirklich schnell, aber erträglich. AFAIR wird GCC 2.95.x (C und C++) in ca. 3 Minuten gebaut. |
|||||
gni
User
2008-09-24, 13:14 h [ - Direct link - ] |
topic: AmiBlitz will nicht, welche alternative ist die Beste ?
Board: Programmierung Zitat:Ohne Ihm jetzt zu nahe treten zu wollen, aber es ist schon des öfteren vorgekommen das Patches oder Systemersatz-Software für unerklärliche Fehler gesorgt hat. Du erinnerst Dich bestimmt an Dein picture.datatype Debakel... |
|||||
gni
User
2008-09-09, 08:15 h [ - Direct link - ] |
topic: Partitionen auf USB-Stick
Board: Amiga, AmigaOS 4 Zitat:Warum soll die 4GB Beschränkung keine Bedeutung beim Booten von an der Deneb angeschlossenen Massenspeichern haben? |
|||||
|
Masthead |
Privacy policy |
Netiquette |
Advertising |
Contact
Copyright © 1998-2024 by amiga-news.de - all rights reserved. |