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

amiga-news.de Forum > Suche [ - Suche - Neue Beiträge - Registrieren - Login - ]

Erste << 12 13 14 15 16 -17- 18 19 20 21 22 >> Letzte Ergebnisse der Suche: 1106 Treffer (30 pro Seite)
gni   Nutzer

12.07.2005, 15:35 Uhr

[ - Direktlink - ]
Thema: StormC 4 oder GoldED Studio AIX: C/C++ IDE
Brett: Programmierung

Zitat:
Solar:
emerge gcc (Gentoo Linux)
iexplore http://www.cygwin.com/setup.exe (Windows)

Es geht auch mit einem stink-normalen make.
Zitat:
Wer da auf GCC schimpft, schimpft auf den falschen.
Hast Du schon mal versucht ältere GCC Versionen mit einem aktuellen GCC zu übersetzen?
 
gni   Nutzer

12.07.2005, 15:29 Uhr

[ - Direktlink - ]
Thema: StormC 4 oder GoldED Studio AIX: C/C++ IDE
Brett: Programmierung

Zitat:
whose:
Zu der Zeit war der GCC keinen Deut besser als Maxon/Storm/Hisoft.

IMHO war er besser. Heutige Versionen sind halt besser als die damaligen.
Zitat:
Die Compiler gabs damals schon und der StormC unterstützte halt WOS. Weil die Unterstützung auf dem Linker basiert, wäre es auch für die anderen Compiler kein großes Thema gewesen, daß einzubauen.
Als P5 mit PPC anfing, gab es keine PPC Version von Storm. Die kam erst später. Den Hinweis auf den Linker kann ich jetzt nicht nachvollziehen.
Zitat:
Weil die Originalquellen eigentlich gar nicht darauf ausgelegt waren, eine WOS-Version zu erzeugen.
Doch waren sie, nur das es anscheinend nur für Jarmo Lakkonen (sp?) funktioniert hat.
Zitat:
Daß das trotzdem (auch mit den Originalquellen!) funktionierte, war ein ganz besonders finsterer Trick. Erinnerst Du Dich? Die "24Bit-Reloc"-Warnungen einfach überlesen und nochmal compilieren ;)
Oder den Linker korrigieren? Ich hätte kein Vertrauen in ein Programm, das so erstellt worden ist. Das es ohne Warnungen geht, zeigt vlink.
Zitat:
Meiner Meinung nach wäre es schlauer gewesen, die libmad-Teile komplett vom Library-Gerüst zu trennen.
Sind sie doch. Oder meinst Du jetzt wrap_mpega.c?
Zitat:
Auf dem Weg kann man dann (wie es der Storm-WOS für mixed binaries/Libraries erwartet) einen 68K-Teil und einen PPC-Teil getrennt compilieren. Da brauchts das #ifdef-Chaos höchstens im Library-Teil, wobei die WOS-Version dem Compiler als gewöhnliche 68K-Library (mit eingebetteten PPC-Funktionen) erscheint.
Das ist doch genau so gelöst. Der Unterschied ist, das Storm sich noch Stubfunktionen generiert. Warum eine Lösung die nur mit einem System funktioniert? Es geht auch ohne solche Stubfuktionen und man kann __saveds auf der PPC Seite sogar weglassen.
Zitat:
Der große Nachteil von PUP war halt, daß man bei Libraries ziemlich aufwendig mit Gate-Funktionen arbeiten muß. Das kannst Du Dir unter WOS sparen, denn das erledigt da der Linker :D
Auch WOS braucht Gates, um von 68k zum PPC zu kommen. Der Unterschied ist, das PUP mit Nachrichten arbeitet und WOS direkt den PPC-Code ausführen läßt.
 
gni   Nutzer

12.07.2005, 11:43 Uhr

[ - Direktlink - ]
Thema: StormC 4 oder GoldED Studio AIX: C/C++ IDE
Brett: Programmierung

Zitat:
whose:
Zitat:
gni:
Ich finde es zeigt auf jeden Fall das die Wahl von P5 begründet war.

Zu dieser Zeit war die Wahl am Markt vorbei, denn da gab es noch Compiler, die weiterentwickelt wurden.
Wenn die Wahl falsch gewesen wäre, dann würde heute niemand dieses Modell benutzen. Es ist aber weit verbreitet!? Und welche Wahl soll es denn gegeben haben? Damals gab es nix. Mit hypothetischen Weiterentwicklungen kann man nix anfangen.
Zitat:
Der Hemmschuh ist schlicht und ergreifend die fürchterlich Unix-orientierte Installation & Bedienung des GCC.
Die einen lieben es, die anderen nicht.
Zitat:
Frag doch mal nen Anfänger, ob der mit dem Compiler gut klarkommt und sich damit wohlfühlt. Jede Wette, die Antwort wird lauten "Der Compiler ist viel zu kompliziert, damit machts nicht wirklich Spaß zu arbeiten".
Das Thema ist bereits durchgekaut.
Zitat:
Oder was meinst Du, warum viele Profi-Entwickler auf den MS-Compiler und dessen IDE schwören? Nur weils so schön bunt ist? Oder könnte etwas dran sein, daß ne IDE den Arbeitsfluß verbessert?
Welchen Umkehrschluß soll ich jetzt ziehen? Kein MS-Compiler+IDE == kein Profi?
Zitat:
Apropos: mpega LibMad war mit dem Storm in <30 Sekunden zusammengeklickt.
Nur komisch das es mit den Originalquellen trotzdem nicht lief. Und es haben ja mehrfach Leute versucht, eine WOS Version mit StormC zu erstellen, ohne Erfolg .-)
Zitat:
Wäre das #ifdef-Wirrwarr nicht gewesen, wäre die in einer Minute fertig compiliert.
Wie macht man es besser? Die Bibliothek ist für mehrere Systeme gedacht und so muß man irgendwie kappseln.
 
gni   Nutzer

11.07.2005, 16:09 Uhr

[ - Direktlink - ]
Thema: StormC 4 oder GoldED Studio AIX: C/C++ IDE
Brett: Programmierung

Zitat:
whose:
Zitat:
gni:
Findest Du das nicht selber grotesk, daß OS4 das PowerUp-ABI verwendet und jetzt eine Emulation für WOS (das ein anderes ABI benutzt) braucht?

*hüstel* ich glaube, das ABI hat nen völlig anderen Namen ;)
Es ging mir auch nicht um den Namen des ABI ;-) PowerUp/ELF wurden immer niedergemacht und dann geht OS4 diesen Weg...
Zitat:
Ich denke, das ABI wurde hauptsächlich darum gewählt, um relativ problemlos an den GCC nebst Tools und Debugger zu kommen.

Für die Unix-gestählten Entwickler sicher die richtige Entscheidung, für alle anderen ein Hemmschuh erster Ordnung...

Warum war/ist es für einen Teil ein Hemmschuh? Ich finde es zeigt auf jeden Fall das die Wahl von P5 begründet war. Seinen eigenen Compiler zu pflegen ist ein sehr aufwändige Sache. Da fällt mir ein: 64bit LinuxPPC benutzt das PowerOpen-ABI ;-)
 
gni   Nutzer

11.07.2005, 13:58 Uhr

[ - Direktlink - ]
Thema: StormC 4 oder GoldED Studio AIX: C/C++ IDE
Brett: Programmierung

Zitat:
whose:
Zitat:
Original von gni:
Die Anpassung des GCC2 WOS-Compiler ist leider nicht so einfach möglich, wie die der PUP Variante (die gibts von GCC2 bis GCC4).

Warum eigentlich nicht?
Weil die Änderungen für WOS umfangreicher sind. Da muß an mehreren Stellen in den Quellcode des GCC eingegriffen werden. Diese Änderungen sind problematisch, weil sich diese Stellen bei neueren GCC-Versionen geändert haben. Für PowerUp erledigt man das meiste über den Port-Header und die anderen Änderungen waren an weniger problematischen Stellen. PowerUp verwendet halt ein Standard-ABI ;-)
Zitat:
Die Sourcen des Storm-GCC sind doch vorhanden. Mit ein bißchen Know-How... ;)
Vieleicht habe ich ja mal irgendwann das Know-How ;-)
Zitat:
Ich denke aber, daß Du mit Deiner Vermutung ins Schwarze triffst: StormC-IDE für den OS4-GCC. Das wäre so ziemlich das, was man bräuchte und was relativ einfach machbar wäre.
Was anderes hätte mich jetzt auch überrascht.
Zitat:
StormC-WOS ginge zwar jetzt theoretisch auch
Findest Du das nicht selber grotesk, daß OS4 das PowerUp-ABI verwendet und jetzt eine Emulation für WOS (das ein anderes ABI benutzt) braucht?
Zitat:
Hast Du die WOS-Version der mpega-LibMad aus den entrümpelten Sourcen bekommen?
Habe ich. Die funktioniert auch, aber ich bin bei "meinen" Versionen geblieben ;-)
 
gni   Nutzer

11.07.2005, 12:43 Uhr

[ - Direktlink - ]
Thema: StormC 4 oder GoldED Studio AIX: C/C++ IDE
Brett: Programmierung

Zitat:
whose:
Zitat:
gni:
IMO GCC 3.x ist auch für m68k besser als GCC2.

Das ihr Compiler-Jungs Euch nicht einig werden könnt... vor nicht allzu langer Zeit war der 2.x noch das Optimum ;)
Seit ich 3.3 kenne/habe, ist bei GCC2 für m68k bei mir auf dem Altenteil ;-)
Zitat:
Zitat:
Zitat:
(und für WOS halt nicht einsetzbar).
Das muß ja nicht so bleiben ;-)
Wäre wünschenswert :D
Die Anpassung des GCC2 WOS-Compiler ist leider nicht so einfach möglich, wie die der PUP Variante (die gibts von GCC2 bis GCC4).
Zitat:
Zitat:
Von StormC für OS4 habe ich noch nie gehört.
Ist ja auch noch in Arbeit, daher "so lange StormC _nicht_ für OS4 verfügbar ist" I-)
Ich wollte eigentlich etwas mehr zu dem Thema hören ;-) Wer macht das, welche Compiler Version, welches ABI (StormGCC steht ja mehr für WOS als PPC). Für mich klingt das ganze nach OS4 GCC in der StormIDE :-)

[ Dieser Beitrag wurde von gni am 11.07.2005 um 12:44 Uhr editiert. ]
 
gni   Nutzer

11.07.2005, 11:07 Uhr

[ - Direktlink - ]
Thema: StormC 4 oder GoldED Studio AIX: C/C++ IDE
Brett: Programmierung

Zitat:
whose:
Die "Verbesserungen" des GCC 3.x sind für 68K wohl eher marginaler Natur

IMO GCC 3.x ist auch für m68k besser als GCC2.
Zitat:
(und für WOS halt nicht einsetzbar).
Das muß ja nicht so bleiben ;-)
Zitat:
Für OS4/MOS ist GoldEd sicher die geeignetere Alternative, so lange StormC nicht für OS4 verfügbar ist.
Von StormC für OS4 habe ich noch nie gehört.

[ Dieser Beitrag wurde von gni am 11.07.2005 um 11:08 Uhr editiert. ]
 
gni   Nutzer

07.07.2005, 10:56 Uhr

[ - Direktlink - ]
Thema: Amiga 1000 Phönix Motherboard Sammelbestellung
Brett: Amiga, AmigaOS 4

Zitat:
GB97816:
Entgegen der Beschreibung muss der Aufruf aber so erfolgen: [...]

Ich habe das Programm (oder einen Namensverwandten ;-) zwar im Pfad, aber ich habe es selber noch nie gebraucht.
 
gni   Nutzer

06.07.2005, 09:56 Uhr

[ - Direktlink - ]
Thema: Amiga 1000 Phönix Motherboard Sammelbestellung
Brett: Amiga, AmigaOS 4

Zitat:
GB97816:
Bei MayFlower ist das Prg. Memory enthalten. Mit ihm kann man nachträglich die Reihenfolge der Einträge in der Memory-Liste (oder wie das Ding auch immer sich nennt) ändern.

Es gibt mehr Programme, die das können. Z.B. ChangeMemPri
 
gni   Nutzer

04.07.2005, 17:40 Uhr

[ - Direktlink - ]
Thema: Cyberpatcher oder Oxyron-Patcher...
Brett: Amiga, AmigaOS 4

Zitat:
GREX:
dieses Programm-Paket [MMULib] richtet sich wahrscheinlich aber auch eher an Entwickler, als an "Normalverbraucher".

Nein, tut es nicht. Das Paket war der Versuch MMU-Programmierung ein API zu verpassen und so die Unterschiede der einzelnen Prozessoren zu verstecken. Ein netter Nebeneffekt des Projektes waren eine 680[46]0.library, die die mmu.library benutzen.
 
gni   Nutzer

02.07.2005, 16:48 Uhr

[ - Direktlink - ]
Thema: BMP-Reader
Brett: Programmierung

Zitat:
Ralf27:
Und, die GadTools gehört doch ab OS2.04 dazu, ist also keine extralib von sonstwoher.

Gadtools ist OS-Bestandteil seit 2.0. BTW, es gibt auch ein Version für OS 1.2/1.3.
 
gni   Nutzer

30.06.2005, 09:20 Uhr

[ - Direktlink - ]
Thema: neueste boards.library?
Brett: Amiga, AmigaOS 4

@DaxB:
Ich habe bei mir WhichAmiga 1.3.22 verwendet, die .23 hing sich auf. Eventuell tritt der Fehler ja nur bei bestimmten System-Konfigurationen auf. Ich habe diverse Erweiterungen in meinem System, einige kennt die Library nicht bzw. identifiziert sie falsch. Zum Debuggen habe ich keine Lust. Ich habe aber proberweise die 2.29 gepatcht (den fraglichen Puffer vergrößert) und danach gab es keine Hits mehr. Allerdings war der Puffer in älteren Versionen der Library genauso groß wie bei der 2.29. Dennoch kann man daraus keine genaue Diagnose stellen, wo denn nun der Fehler liegt.
 
gni   Nutzer

29.06.2005, 16:48 Uhr

[ - Direktlink - ]
Thema: neueste boards.library?
Brett: Amiga, AmigaOS 4

Zitat:
DaxB:
Also hier gibt MuGuardianAngel nichts aus beim öffnen der boards.library 2.29. Was machst du um die Ausgabe zu erhalten?

Hast Du auch Sushi/Sashimi laufen? Nur dann bekommt man Ausgaben von Debug-Tools zu sehen. Einfach WhichAmiga starten und der MuGA-Hit kommt. Eventuell ist es auch ein Bug in WhichAmiga (1.3.2x).
Zitat:
WhichAmiga 1.3.23 (9.11.01): Öffnet im gegensatz zu 1.3.3 (2.5.99) immer einen schwarzen Bildschirm, der wenn WhichAmiga fertig ist, wieder geschlossen wird. Kann das jemand bestätigen?
Yep, passiert auch mit 1.3.22.

[ Dieser Beitrag wurde von gni am 29.06.2005 um 16:49 Uhr editiert. ]
 
gni   Nutzer

29.06.2005, 09:14 Uhr

[ - Direktlink - ]
Thema: neueste boards.library?
Brett: Amiga, AmigaOS 4

Zitat:
DaxB:
Hier läuft WhichAmiga 1.3.3 (2.5.99) und boards.library 2.29 (11-Jan-2001) ohne Probleme.

Die boards.library 2.29 scheint über das Ende eines ihrer Puffer zu schreiben. Das zumindest teilt mit MuGuardianAngel mit. Eine ältere Version der boards.library macht das nicht. Fazit: Finger weg von 2.29.
 
gni   Nutzer

28.06.2005, 15:47 Uhr

[ - Direktlink - ]
Thema: BMP-Reader
Brett: Programmierung

Zitat:
whose:
@Ralf: Mit IDCMP_MENUVERIFY weist Du Intuition an, dir VOR dem Aufbau des Menustrips eine Nachricht zukommen zu lassen (genauer: beim Drücken der rechten Maustaste, Intuition wartet dann mit dem Aufbau des Menustrips, bis Du die Nachricht beantwortet hast).

Und genau hier hat er dann u.U. ein Problem: Die Nachricht muß "schnell" beantwortet werden und man darf keine Intuition-Funktionen aufrufen (weil es sonst zum Deadlock kommen könnte). Ob man vor dem Beantworten noch was mit den Pens per graphics.library machen darf, kann ich nicht sagen.
 
gni   Nutzer

28.06.2005, 15:01 Uhr

[ - Direktlink - ]
Thema: Cyberpatcher oder Oxyron-Patcher...
Brett: Amiga, AmigaOS 4

Zitat:
GREX:
Der Oxypatcher hat übrigens noch einen Vorteil: Er zeigt auf Wunsch die Befehle, die er emuliert hat an.

Das kann man mit den Phase5-Tools auch haben.
 
gni   Nutzer

28.06.2005, 14:21 Uhr

[ - Direktlink - ]
Thema: [?]Frage zu Assembler und Amiga
Brett: Programmierung

Zitat:
Holger:
Es gibt meines Wissens ausschließlich die gcc-Umgebung als offizielle Entwicklungsumgebung.

Spielt das irgendeine Rolle? Hyperion (Amiga wer auch immer) sollten froh sein, das es neben dem GCC noch andere Entwicklungstools gibt.
Zitat:
Damit gibt es exakt einen C/C++ Compiler und exakt einen Assembler für AOS4ppc
FYI, den GNU-Assembler und GNU-Linker kann man ohne weiteres gegen PASM und VLINK austauschen. Das ganze habe ich gerade erfolgreich bei GCC für PowerUp und WarpOS praktiziert (der PowerUp-Compiler ist dem OS4 GCC sehr ähnlich und kann sowohl __libcall als auch __linearvarargs)
Zitat:
neben vielleicht vbcc als puren C-Compiler, aber der ist wahrscheinlich nicht offizielle Entwicklungsumgebung, sondern "nur" 3rd-party Produkt.
Mit dem man dennoch ohne Schwierigkeiten Programme für OS4 übersetzen kann. Es soll ja Leute geben, die den GCC nicht mögen ;-)
 
gni   Nutzer

28.06.2005, 09:11 Uhr

[ - Direktlink - ]
Thema: BMP-Reader
Brett: Programmierung

Zitat:
Ralf27:
Die Idee [Menus ala DPaint] ist schon recht gut, aber wie kann ich das ganze realisieren?

Mit IDCMP_MENUVERIFY.
 
gni   Nutzer

27.06.2005, 10:01 Uhr

[ - Direktlink - ]
Thema: g++ inline asm
Brett: Programmierung

Zitat:
Kaesebroetchen:
P.S. das Codebeispiel ist für windows und ich arbeite mit MinGW, aber die inline asm Syntax müsste doch bei allen gcc/g++ gleich sein ?

Die grundlegende Struktur ja. Der Unterschied liegt in den Registern und Constraints. Mehr über "ExtendedASM" findest Du hier klick


Ich würde Dir vorschlagen, entweder komplett ohne ASM auzukommen oder C und Asm zu trennen.
 
gni   Nutzer

17.06.2005, 08:32 Uhr

[ - Direktlink - ]
Thema: Character im Filenamen zählbar?
Brett: Programmierung

Zitat:
NoImag:
Zitat:
Crystal:
Bleibt noch die Frage, wie man die Characters im Filenamen addiert...?(

Ein Programm dafür kenne ich nicht. Leerzeichen musst du selbstverständlich alle mitzählen.
wc (ist ein UN*X Befehl, den es sicher auch ixemulfrei für AmigaOS gibt.
 
gni   Nutzer

15.06.2005, 09:24 Uhr

[ - Direktlink - ]
Thema: ilbm.datatype friss ChipMem
Brett: Programmierung

Zitat:
MaikG:
Kann man vermeiden das der ilbm.datatype Chipspeicher nimmt?

Die Frage läßt sich ohne weitere Informationen über Dein System nicht beantworten. Zum einen: welcher ilbm.datatype (version full *ohne* die file Option!) und zum anderen welches Grafiksystem?
 
gni   Nutzer

14.06.2005, 10:49 Uhr

[ - Direktlink - ]
Thema: guigfx+renderlib Linker Fehler
Brett: Programmierung

Zitat:
DariusBrewka:
Zitat:
Wie Du hier sehen kannst, wird ein #pragma Header eingebunden. Dies bedeutet, das dieser proto/ Header *nicht* für den GCC geeignet ist.
wieso soll das nicht gehen, schliesslich geht es bei mir ja auch, in meinem proto header werden auch nirgends pragmas eingebunden.
Der bei Käsebrötchen verwendete pragmas/ Header ist definitiv nicht für den GCC, ansonsten hätte er keine Linkerfehler bekommen. Man kann proto/ Header verwenden, die einen pragmas/ Header einbinden, wenn der der dann den entsprechenden inline/ Header anzieht :-) Ich habe solche Wrapper installiert, damit ich bei Bedarf "alte" SAS/C Quellen mit weniger Änderungen übersetzen kann.
Zitat:
code:
#ifndef _PROTO_GUIGFX_H
#define _PROTO_GUIGFX_H

#ifndef EXEC_TYPES_H
#include <exec/types.h>
#endif
#ifndef CLIB_GUIGFX_PROTOS_H
#include <clib/guigfx_protos.h>
#endif

#ifndef __NOLIBBASE__
extern struct Library *GuiGFXBase;
#endif

#ifdef __GNUC__
#include <inline/guigfx.h>
#elif !defined(__VBCC__)
#include <pragma/guigfx_lib.h>
#endif

#endif	/*  _PROTO_GUIGFX_H  */

Diese includes habe ich auch geschickt, ggf. irgendwo was falsch hinkopiert?
Sieht ganz so aus.

[ Dieser Beitrag wurde von gni am 14.06.2005 um 10:50 Uhr editiert. ]
 
gni   Nutzer

14.06.2005, 09:58 Uhr

[ - Direktlink - ]
Thema: guigfx+renderlib Linker Fehler
Brett: Programmierung

Zitat:
Kaesebroetchen:
Vielleicht kann mir ja mal jemand das Zusammenspiele der verschiedenen Includes / Verzeichnisse erklären ?

Wenn Du mit -v übersetzt, dann werden die verwendeten Includeverzeichnisse angezeigt. Im zuerst genannten Verzeichnis wird auch zuerst nach Includes gesucht.
 
gni   Nutzer

14.06.2005, 09:56 Uhr

[ - Direktlink - ]
Thema: guigfx+renderlib Linker Fehler
Brett: Programmierung

Zitat:
Kaesebroetchen:
code:
3.AmigaDev:cpp/guig> gcc -H -o gu2 guigf.c
[...]
. /gg/include/proto/guigfx.h
.. /gg/include/clib/guigfx_protos.h
.. /gg/include/pragmas/guigfx_pragmas.h


Wie Du hier sehen kannst, wird ein #pragma Header eingebunden. Dies bedeutet, das dieser proto/ Header *nicht* für den GCC geeignet ist.
Zitat:
code:
. /gg/include/proto/render.h
.. /gg/include/clib/render_protos.h
.. /gg/os-include/inline/render.h


Der Header für die render.library ist ok. Entweder Du erzeugst Dir mit fd2pragma (special 36) bzw fd2inline einen passenden proto/ Header oder Du editierst den vorhandenen analog zu zb. proto/render.h.
 
gni   Nutzer

14.06.2005, 08:58 Uhr

[ - Direktlink - ]
Thema: guigfx+renderlib Linker Fehler
Brett: Programmierung

Zitat:
Kaesebroetchen:
Beim compilieren kriege ich aber immer nach fehler:
code:
4.AmigaDev:cpp/guig> gcc guigf.c -o guig2
/t/ccEnZWes.o(.text+0x174): undefined reference to 'LoadPicture'
/t/ccEnZWes.o(.text+0x1c8): undefined reference to 'GetPictureAttrs'
/t/ccEnZWes.o(.text+0x240): undefined reference to 'ObtainDrawHandle'
/t/ccEnZWes.o(.text+0x262): undefined reference to 'DrawPicture'
/t/ccEnZWes.o(.text+0x286): undefined reference to 'ReleaseDrawHandle'
/t/ccEnZWes.o(.text+0x2c2): undefined reference to 'DeletePicture'
collect2: ld returned 1 exit status
4.AmigaDev:cpp/guig>


Compiliere mal mit -O. Welche Ausgaben bekommst Du, wenn Du -H beim übersetzen benutzt? Steht dann da irgendwas über das guigfx bzw. render Inline?
 
gni   Nutzer

14.06.2005, 08:56 Uhr

[ - Direktlink - ]
Thema: guigfx+renderlib Linker Fehler
Brett: Programmierung

Zitat:
Original von DariusBrewka:
Zitat:
Die Includes die du mir gemailt hast, habe ich nach gg:include/ kopiert. Irgendwas fehlt da wohl noch.
das ist der fehler, die gehören beim gcc nach os-include!
Der nativ-GCC sucht an mehreren Stellen nach Includes: gg:local/include, gg:<Pfad zur compiler version>/include, gg:m68k-amigaos/include, gg:os-include und gg:include. Bis auf das Compilerspezifische Verzeichnis kannst Du Includes in jedes dieser Verzeichnis packen. Allerdings sollte man die System-Verzeichnisse gg:include und gg:os-include besser nicht für eigene Includes benutzen. Damit behält man Übersicht und hat eine klare Trennung von System und 3rd-party Headern.

Und nur so am Rande: Neuere Versionen des GCC werden GG: *nicht* mehr benutzen. Die werden sich dann brav an den Quasi-Standard USR: bzw. USR:LOCAL halten. Für gg:include und gg:os-includse wird das keinen Unterschied machen, da bei GeekGadgets gg: == usr:.
 
gni   Nutzer

09.06.2005, 13:19 Uhr

[ - Direktlink - ]
Thema: Executablename aus Prozessstruktur ermitteln?
Brett: Programmierung

Zitat:
DariusBrewka:
Hallo gibt es einem Möglichkeit aus der Prozessstruktur/TaskStruktur den dazugehörigen Namen des Files zu erfahren, d.h. nicht wie der Task heisst sondern wie das Programm auf der Platte heisst?

Für Workbench-gestartete Programme könntest Du in der WB-Startupmessage nachschauen.
 
gni   Nutzer

08.06.2005, 11:34 Uhr

[ - Direktlink - ]
Thema: Amiga 600: Wer braucht ernsthaft eine FPU?
Brett: Amiga, AmigaOS 4

Zitat:
JSchoenfeld:
Ist Linux wirklich auf ne FPU (Fließkomma-Rechnerei!) angewiesen, oder verwechselst Du das mit der MMU?

AFAICT braucht man eine FPU für UN*X sei es nun Linux oder NetBSD. Deren FPU Emulation ist nicht so toll. Nur wer will auf einem A600 ernsthaft was anderes als AmigaOS verwenden?
 
gni   Nutzer

03.06.2005, 17:22 Uhr

[ - Direktlink - ]
Thema: AHI-Fragen
Brett: Amiga, AmigaOS 4

Zitat:
uwi_u:
>version mpega.library full zeigte mir folgendes:

Version 2.4 vom 13.09.1999
"[PPC] MPEG Audio Decoding library"

Allerdings ist diese Library nur 3208 Bytes groß und braucht wohl eine der beiden .elf Dateien zum korrekten arbeiten.

Dies ist die PowerUp-Verion der Original-mpega Bibliothek. Da ist der PPC-Code in einer separater Datei mit der Endung ".elf".
 
gni   Nutzer

03.06.2005, 17:20 Uhr

[ - Direktlink - ]
Thema: AHI-Fragen
Brett: Amiga, AmigaOS 4

Zitat:
Brunadi:
@Thomas

Stimmt. Habe die Version 2.4 WOS v.23.6.02 installiert.

Das ist die 6te Version der mpega_libmad, dh. das ist der der mpega-clone.

[ Dieser Beitrag wurde von gni am 03.06.2005 editiert. ]
 
 
Erste << 12 13 14 15 16 -17- 18 19 20 21 22 >> Letzte Ergebnisse der Suche: 1106 Treffer (30 pro Seite)

Suchbegriffe
Schlüsselwörter      Benutzername
Suchoptionen
Nur in diesen Foren suchen
   nur ganze Wörter
Nur Titel anzeigen
alle Treffer anzeigen

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