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 << 11 12 13 14 15 -16- 17 18 19 20 21 >> Letzte Ergebnisse der Suche: 1106 Treffer (30 pro Seite)
gni   Nutzer

02.08.2005, 09:53 Uhr

[ - Direktlink - ]
Thema: GCC installieren
Brett: Programmierung

Zitat:
Dietmar:
@gni:
Zitat:
Welche möchtest Du haben? ;-) Wenn ich endlich die Zeit finde, dann habe ich vor folgendes zu veröffentlichen:

2.95.4: m68k, PowerUp, WarpOS
3.3.6, 3.4.3, 4.0.x, 4.1.x: m68k, PowerUp

Ist das eine Fangfrage? Also ich nehme alle :)
Die Frage war ernst gemeint. Alle diese Ports gibt es wirklich. Ich hoffe bald die notwendige Zeit zum Bauen von Archiven zu finden.
Zitat:
Wie sieht denn 4.x geschwindigkeitsmässig aus und kannst Du schon abschätzen, wie ausgereift diese Versionen sind?
Nach Aussagen der Entwickler soll 4.0 beim Übersetzen nicht langsamer sein als 3.4, gelegentlich sogar schneller. Mir kommt das aber nicht so vor. Wie gut/schlecht 4.0 ist, kann ich nicht so recht beurteilen, aber IMHO hat es sich für m68k eher verschlechtert denn verbessert. Das ist auch ein Grund, warum ich es noch nicht für nötig hielt, einen 4.0 Port zu veröffentlichen. Ich nehme vorwiegend 3.3.3.
 
gni   Nutzer

01.08.2005, 15:48 Uhr

[ - Direktlink - ]
Thema: GCC installieren
Brett: Programmierung

Zitat:
Amaris:
Hmm...kann mir vielleicht jemand etwas zu "StormC4" sagen ?
Ich habe gesehen daß das ja wirklich nur noch 49,95 kostet. Das könnte ich noch investieren. Lohnt sich das ?

Darauf gibt es keine objektive Antwort ;-) Ich würde das Geld anders ausgeben, aber ich bin eh voreingenommen *g*
 
gni   Nutzer

01.08.2005, 13:56 Uhr

[ - Direktlink - ]
Thema: GCC installieren
Brett: Programmierung

Zitat:
DariusBrewka:
Zitat:
Was hat nicht mehr geklappt? 3.x verwendet die selben Include- und Bibliotheksverzichnisse 2.x.
das compilieren ohne einen Pfad zu den Includes expilzit anzugeben (-I...), bei GCC2.9 von geekgadgets hat das alles auf anhieb geklappt bei 3.x hat er immer gemeckert das er die Includes nicht findet.
gcc -v zeigt Dir, wo der Compiler Includes sucht. In diesem Bereich gibt es defintiv keine Unterschiede.
Zitat:
Wie dem auch sei, inzwischen werde ich meine Amiga-Programme nur noch unter Linux compilieren, da stand auch in der Installationsanleitung os includes nach /opt/gg/os-include/amigaos, aber weder das hat geklappt noch /opt/gg/os-include.
Welche Anleitung? Woher ist der Compiler? Poste bitte die -v Ausgabe des Frontends und die Ausgaben von "Frontend -v -x c -c /dev/null".
 
gni   Nutzer

01.08.2005, 13:52 Uhr

[ - Direktlink - ]
Thema: GCC installieren
Brett: Programmierung

Zitat:
Dietmar:
@gni:
Zitat:
Demnächst usr:local/m68k-amigos/lib.
Bezieht sich "demnächst" auf adltools
Vorerst nicht. Dessen Repository enthält zu viel Ballast IMHO.
Zitat:
und falls ja: auf welche gcc-Version für 68k kann man hoffen?
Welche möchtest Du haben? ;-) Wenn ich endlich die Zeit finde, dann habe ich vor folgendes zu veröffentlichen:

2.95.4: m68k, PowerUp, WarpOS
3.3.6, 3.4.3, 4.0.x, 4.1.x: m68k, PowerUp

Keiner dieser Versionen wird mehr gg: sondern usr:local verwenden. Aus gg:[os-]include wird usr:[os-]include. Da aber gg: == usr: ist das nicht weiter tragisch. Das spezielle GG Layout war IMHO ein böser Fehler. Der 2.95.4 Port existiert deshalb, weil es den WarpOS-GCC bisher nur für diese Version gibt und da wollte ich es vollstäding haben (Der erzeugte Code von 2.95.4 ist identisch zu 2.95.3).
Es gibt aber keinen definitiven Zeitpunkt.
 
gni   Nutzer

01.08.2005, 13:41 Uhr

[ - Direktlink - ]
Thema: GCC installieren
Brett: Programmierung

Zitat:
Holger:
Zitat:
gni:
Nein, dh. GCC 3.x sucht teilweise relativ von der Stelle an der sich sein Frontend befindet.

welches doch in GG:bin zu finden sein sollte, oder? Dann wär's letztendlich trotzdem relativ zu diesem Pfad.
Wie gesagt: teilweise. Das Frontend _vesucht_ den Compiler, einige der Include- und Bibliotheksverzeichnisse so zu finden. Man kann sich das mit -v anschauen.
 
gni   Nutzer

01.08.2005, 11:57 Uhr

[ - Direktlink - ]
Thema: gcc-warpup: Wo gibts den noch?
Brett: Programmierung

Zitat:
whose:
Zitat:
gni:
ich würde dennoch versuchen, einen Compiler zu verwenden, der echen WarpOS-Code erzeugt. Die "Krücken" machen alle ELF aka SYSV-Code, für die es allerdings eben auch eine C lib gibt :-(

Also meinst Du, es wäre besser, den möglicherweise harten Weg mit dem vbcc zu gehen...
Versuchen würde ich es damit, ja. Hoffentlich sind die Quellen nicht mit der Annahme "es gibt nur GCC" geschrieben ;)
Zitat:
ich werds versuchen. Darf ich dann auch mit ggf. auftauchenden "dummen" Fragen nerven? :)
Wenn Du keine Antworten erwartest :-)
 
gni   Nutzer

01.08.2005, 11:51 Uhr

[ - Direktlink - ]
Thema: gcc-warpup: Wo gibts den noch?
Brett: Programmierung

Zitat:
whose:
Zitat:
Original von gni:
Die Compiler benutzt man auch nur über das Frontend. Vermutlich weis niemand, wie es ohne Frontend geht ;-)

Ausweia... ;)
Üblicherweise benutzt man Compiler über deren Frontend. Das ist auch bei VBCC so. Die Frontend wissen am besten, wo die Compiler sich befinden und mit welchen Optionen man sie aufrufen muß.
 
gni   Nutzer

01.08.2005, 11:43 Uhr

[ - Direktlink - ]
Thema: GCC installieren
Brett: Programmierung

Zitat:
whose:
Für den GCC kann ich dir später ein kleines Listing zusammenstellen, welche Dateien sich wo im Verzeichnisbaum der GG-Installation befinden. Gültig für den GCC 3.4, sollte aber beim 2.95.3 das Gleiche sein.

2.95.x und 3.4 unterscheiden sich im Verzeichnislayout.
 
gni   Nutzer

01.08.2005, 11:41 Uhr

[ - Direktlink - ]
Thema: GCC installieren
Brett: Programmierung

Zitat:
DariusBrewka:
eigentlich brauchst du auch nichts in die User startup und so eintragen nur ein "Path GG:bin add" sollte reichen, den rest erledigt gcc relativ zu diesem pfad.

Nein, dh. GCC 3.x sucht teilweise relativ von der Stelle an der sich sein Frontend befindet.
Zitat:
die os-includes gehören AFAIK nach gg:os-includes
Richtig. Demnächst usr:os-include ;-)
Zitat:
die linker-libs nach gg:os-lib
Nein. Die 68k-Bibliotheken gehören allesamt nach gg:m68k-amigaos/lib. Demnächst usr:local/m68k-amigos/lib.
Zitat:
du musst aber noch aus den fd files für den GCC die richtigen inlines machen,ich hab's mit fd2pragma gemacht aber AFAIK gibt's beim gcc irgendwo das Commando fd2inline.
Ausser den Inline brauchts auch noch passende proto/ Header, damit die Inlines auch benutzt werden. Ob man nun fd2pragma verwendet oder fd2inline ist egal.
Zitat:
Ich kenne das Problem aber auch, in den Installationsanleitungen steht dass die includes da und da hingehören, klappen tut's aber nie
Oh doch!
Zitat:
und wenn dem so ist, kannst du auch beim Compilieren den Pfad zu den Includes angeben "gcc .... text.c -Iincludepfad -Llinklibpfad", dass hat immer geklappt.

Das gesagte gilt für gcc 2.95, bei 3.x hat's bei mir aber auch nicht mehr geklappt.

Was hat nicht mehr geklappt? 3.x verwendet die selben Include- und Bibliotheksverzichnisse 2.x.
 
gni   Nutzer

01.08.2005, 11:28 Uhr

[ - Direktlink - ]
Thema: gcc-warpup: Wo gibts den noch?
Brett: Programmierung

Zitat:
whose:
ich denke, DukeNukem für WOS wurde mit einer der "Krücken" übersetzt. Ich will der ganzen Angelegenheit ja nur den Sound wiedergeben ;)

Das verstehe ich zwar, aber ich würde dennoch versuchen, einen Compiler zu verwenden, der echen WarpOS-Code erzeugt. Die "Krücken" machen alle ELF aka SYSV-Code, für die es allerdings eben auch eine C lib gibt :-(
 
gni   Nutzer

01.08.2005, 11:24 Uhr

[ - Direktlink - ]
Thema: gcc-warpup: Wo gibts den noch?
Brett: Programmierung

Zitat:
whose:
Zitat:
gni:
Wenn man StormGCC in der Shell benutzen kann, sollte sich der Compiler mit make benutzen lassen.

In der Theorie geht es wohl, mir ists allerdings zu aufwändig, die ganzen Umbauten im makefile vorzunehmen. Frontend ala "gcc" gibts da wohl keins...
Wenn es kein Frontend gibt, dann kann man die Verwendung in der Shell vergessen.
Zitat:
Wie gesagt, das "gewohnte" Frontend gibts da wohl nicht und "cc1" habe ich noch nie aus der Shell heraus genutzt. Ich wüßte da gar nicht, worauf ich achten muß...
Die Compiler benutzt man auch nur über das Frontend. Vermutlich weis niemand, wie es ohne Frontend geht ;-)
Zitat:
Naja, ich bin faul... I-) bei der libmad gings via IDE ja ganz gut, weil man (Du :D ) da auf Sperenzchen im makefile verzichtete...
Keine Ahnung was Du meinst. Das Makefile ist nicht ohne. Ich habe eine Weile gebraucht, bis ich dessen Design verstanden hatte. Dieses Makefile ist schon was besonderes, das mit nur einem Makefile Versionen für MOS, OS4, 68k, PowerUp und WarpOS erstellen lassen. So ein Design habe ich für meine xpkGZIP Bibliothek nicht hinbekommen. Da habe ich separate Makefiles für 68k, PUP und WOS.
 
gni   Nutzer

01.08.2005, 11:14 Uhr

[ - Direktlink - ]
Thema: IFF-Bilder mit PPT 6.18
Brett: Programmierung

Zitat:
Ralf27:
"BMP-konforme IFF-ILBM-Formate".

Was soll denn das sein?
 
gni   Nutzer

01.08.2005, 11:12 Uhr

[ - Direktlink - ]
Thema: IFF-Bilder mit PPT 6.18
Brett: Programmierung

Zitat:
Ralf27:
Allerdings kann PPT wohl keine 24Bit-BMPs, was ja für mich interesanter gewesen wäre.

Soweit ich weis, kann PPT 24-Bit BMPs sowohl Laden als auch Speichern.
 
gni   Nutzer

01.08.2005, 11:06 Uhr

[ - Direktlink - ]
Thema: gcc-warpup: Wo gibts den noch?
Brett: Programmierung

Zitat:
whose:
Zitat:
Dietmar:
Verstehe ich nicht; kann man den gcc von StormC nicht mit make benutzen? Es wäre jedenfalls die gleiche Version, wenn ich micht nicht irre.

Zumindest größtenteils. Für genaueres solltest Du Gunther Nikl fragen, er meinte, daß die WOS-Anpassung des Storm-GCC nicht ganz sauber implementiert wäre.
Das ist aber hier irrelevant. Wenn man StormGCC in der Shell benutzen kann, sollte sich der Compiler mit make benutzen lassen.
Zitat:
Dazu kommt, daß dieser GCC sich darin vom "normalen" unterscheidet, daß er passend für den StormLink Ausgabe erzeugt.
Und den kann man nicht in der Shell benutzen?
Zitat:
Daher ist es nicht ganz so simpel, den StormC-GCC mit den jeweiligen makefiles zu benutzen I-) Zumindest habe ich bei der mpega-libmad leichte Probleme bekommen, als ich ein simples make versuchte...
:-( Du mußt dem Makefile schon sagen, das Du StormGCC verwendest und wann/wie 68k und PPC Compiler.
 
gni   Nutzer

01.08.2005, 10:56 Uhr

[ - Direktlink - ]
Thema: gcc-warpup: Wo gibts den noch?
Brett: Programmierung

Zitat:
whose:
Letzte Möglichkeit wäre, das Ganze durch den StormC4-GCC zu schicken, aber das ist viel Aufwand, da man erstmal das makefile auseinanderpflücken müßte, um zu schauen, welche Besonderheiten da auf einen warten... :(

Ich würde diese alten WarpUP Versionen nicht verwenden. Das waren immer nur Krücken. VBCC zu benutzen klingt doch gut ;-) Oder eben StormGCC. Den kann man doch in der Shell verwenden? Ansonsten gibt es ja auch einen "echten" GCC für WarpOS, allerdings *ohne* C lib.
 
gni   Nutzer

26.07.2005, 14:17 Uhr

[ - Direktlink - ]
Thema: So darfst Du doch nicht tun!
Brett: Amiga, AmigaOS 4

Zitat:
pixl:
das einzige was mich gewundert hat wieso wird bei 2 Festplatten beim Start das WB Bootbild angezeigt.

Vermutlich sind die Platten nicht angeschlossen.
 
gni   Nutzer

26.07.2005, 09:53 Uhr

[ - Direktlink - ]
Thema: Eine Frage Uber eine 604e CPU
Brett: Amiga, AmigaOS 4

Zitat:
Granada:
Da das Programm "whichamiga" von Harry Sintonen auf meinem 4000er mit neueren Versionen der boards.library nicht mehr zurechtzukommen scheint (es crasht beim "evaluating system...")

Mit einer älteren Version der Library sollte es kein Problem geben.
 
gni   Nutzer

26.07.2005, 09:50 Uhr

[ - Direktlink - ]
Thema: Eine Frage Uber eine 604e CPU
Brett: Amiga, AmigaOS 4

Zitat:
Amiga_Digital:
das version von meine ppc librarty ist 45.1

Diese Version ist uralt. Die aktuellste Version ist 46.x.
Zitat:
und der bios von der cyberstorm ist geupdate
Sicher? Was sagt "version full cybppc.device"?
 
gni   Nutzer

15.07.2005, 16:56 Uhr

[ - Direktlink - ]
Thema: Frage zu 060 CPU / Aminet Softwaretools
Brett: Amiga, AmigaOS 4

Zitat:
060fix

Das sollte Deine 68060 Library bereits erledigen.
Zitat:
FixGetMsg (wird im 060fix empfohlen)
Macht eventuell die 68060 Library auch schon selber. Oder man kann es von Blizkick erledigen lassen.
Zitat:
NewCopyMemQuick
Nö.
Zitat:
Make060 setzt irgendwelche Flags :)
Das brauchst Du auf keinen Fall.

[ Dieser Beitrag wurde von gni am 15.07.2005 um 16:58 Uhr editiert. ]
 
gni   Nutzer

15.07.2005, 16:36 Uhr

[ - Direktlink - ]
Thema: Performance-Wahn: Startup-Sequence optimieren. :-)
Brett: Amiga, AmigaOS 4

Zitat:
DJBase:
Warum also die ganze Zeile lesen, wenn sie auf ignorieren steht.

Wie findest Du den beginn der nächsten Zeile? Es muß immer die komplette Datei inklusive aller Kommentare gelesen werden.
 
gni   Nutzer

15.07.2005, 16:31 Uhr

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

[Doppelposting gelöscht]

[ Dieser Beitrag wurde von gni am 15.07.2005 um 16:32 Uhr editiert. ]
 
gni   Nutzer

15.07.2005, 16:15 Uhr

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

Zitat:
whose:
ich erinnere mich nur noch dunkel an das Poseidon-DevKit, da tauchte alle paar Zeilen ein "#ifdef" "DECLGATE"-Konstrukt auf.

Das hat was mit MorphOS zu tun.
Zitat:
Genau das ganze Drama erledigt bei WOS der Linker. Auch die Namensauflösung. Soweit ich mich erinnere, kommt vor jede ehemalige 68K-Funktion bei einem Mixed Binary ein _PPC..., darüber "weiß" der Linker ja Bescheid. Also kein Namenskonflikt.
Wie erkennt der 68k-Compiler, das eine PPC-Funktion aufgerufen wird? Oder erkennt das der Linker?
Zitat:
Daher ists ja auch (eigentlich, die libmad z.B. weicht von dem Schema gewaltig ab I-) ) simpel, aus 68K-Programmen WOS-Programme zu machen. Ein Compiler-Linker-Zyklus ohne Source-Anpassungen (man muß nur das Projekt mit ein paar Klicks umsortieren) genügt (normalerweise).
IMHO, der mpega_libmad Weg ist flexibler und man ist nicht an ein einziges Compilersystem gebunden.
 
gni   Nutzer

15.07.2005, 09:51 Uhr

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

Zitat:
whose:
Ich meinte mixed binary. Mea culpa. Da isses ja nicht so einfach, da man z.B. bei PUP auf Gate-Funktionen angewiesen ist, die in den 68K-Code eingebaut werden müßen (wenn ich das richtig geblickt habe, wird das z.B. bei MOS hauptsächlich mit Macros erledigt?).

Die Initialisierungsfunktionen schreibt man genau *ein* mal und dann werden sie recycled. Ich sehe da keine wirkliche Einschränkung. Das Nachrichtensystem zu verstehen, ist da schon schwieriger. Steve Kruegers Beispiele (zu finden beim SAS/C PPC) sind da hilfreich.
Zitat:
Bei WOS macht das der Linker, daher kann man mit einem Compiler- (bzw. Linker-) Switch aus dem Mixed ein reines 68K- oder PPC-Binary machen.
Oder eben aus einer ehemaligen Nur-68K-Anwendung einen 68K-WOS-Mix, indem man einen Teil der 68k-Funktionen einfach durch den PPC-Compiler jagt und später das Ganze zu einem Mixed Binary linken läßt. Das war vor allem der große Vorteil von WOS: Man mußte (meistens) an den 68K-Programmen nichts ändern, ein weiterer Compilerlauf, bei dem die für WOS vorgesehenen Funktionen entsprechend ins Projekt eingefügt wurden, genügte meist.

Auch wenn Dir die IDE etwas Arbeit abnimmt, Gatefunktionen werden *auch* bei WOS benötigt. Wobei sich mir die Frage aufdrängt, die Gatefunktion bekommt den Namen der aufzurufenden Funktion, den den selben Namen als PPC Funktion hat. Wie löst man das Dilemma?
 
gni   Nutzer

15.07.2005, 09:30 Uhr

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

Zitat:
Holger:
Zitat:
gni:
PPCLoadObjectTagList() kann ein ELF-Programm sowohl aus einem File als auch aus dem Speicher laden. Eingebette ELF-Programme "verschwenden" allerdings etwas Speicher, haben aber den Vorteil, daß man den ELF-Loadsegpatch nicht benötigt.

Könnte man doch mit overlay-hunks kombinieren...
AFAIK, das geht nicht für shared Libraries.
 
gni   Nutzer

14.07.2005, 10:18 Uhr

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

Zitat:
Holger:
Hmm, ich kann mich erinnern, daß ich damals für powerup eine ziemlich einfache Lösung hatte, bei der das ELF binary, so wie es war, in das 68k Programm eingebettet wurde. Ganz so, wie mancher größere textpassagen oder Bilddaten included hat.

Da gibt es verschiedene Programme, zb. Data2Object. Damit wird aus dem ELF Programm ein Objektfile gemacht, das man dann zum 68k, linkt.
Zitat:
Die powerup-lib hatte eine Funktion, die das ELF-file auch direkt aus dem RAM laden konnte.
PPCLoadObjectTagList() kann ein ELF-Programm sowohl aus einem File als auch aus dem Speicher laden. Eingebette ELF-Programme "verschwenden allerdings etwas Speicher, haben aber den Vorteil, daß man den ELF-Loadsegpatch nicht benötigt.
 
gni   Nutzer

14.07.2005, 10:09 Uhr

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

Zitat:
Holger:
Zitat:
gni:
Mit etwas gutem Willen könnte man das ARexx-Interface aus den StormGCC Quellen extrahieren und dann aktuellere Versionen benutzen, allerdings eben nicht für WarpOS.

Soll heißen, mit WarpOS als target?
Ja.
Zitat:
Inwieweit braucht man eigentlich tatsächlich aktiven support dafür?
Von Hause aus hat GCC keine Einstellung, um WarpOS kompatiblem Code zu erzeugen. Und genau das hat H&P in GCC eingebaut (allerdings inkompatibel zu StormC 3!), aber eben nur für GCC2. GCC3 Anpassung ist Arbeit.
Zitat:
Letztendlich gibt's ja auch ne pup-emu. Also prinzipiell kann man auch konventionellen ppc-code ausführen und alles, worum es Programmierern geht, ist doch ppc-code und 68k-code in einem executable zu verpacken, dem man von außen nicht ansieht, was da alles kompliziertes passiert, oder?
Abgesehen davon, das nicht jedes Programm mit der Emu funktioniert, ist die notwendige Umsetzung der verschiedenen ABI unsauber. Bei WarpOS/EHF kann man das Mischen von 68k und PPC Code vom Linker erledigen lassen. Für ELF braucht man einen Zwischenschritt, der aus dem fertigen PPC-Programm ein 68k-Objekt macht, das man dann zum 68k Code linken kann. So macht das zb. mpega_libmad.
 
gni   Nutzer

13.07.2005, 09:13 Uhr

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

Zitat:
Holger:
Es geht doch wohl darum, daß man den in StormC enthaltenen gcc nicht durch eine aktuelle Version ersetzen kann

Sagen wir es mal so: Theoretisch gehts es. In der Praxis ist es aufwändiger als nötig, weil der Amiga-spezifische Storm-Code nicht sauber vom Rest des Compilers getrennt worden ist.
Zitat:
und daß es sogar noch Leute gibt, die deshalb aktuelle gcc-Versionen schlechtreden und versuchen einen künstlichen Bedarf an veralteten gcc-Versionen herbeizureden.
Ich habe aus den Quellen des StormGCC einen "normalen" Port gemacht. Bis jetzt ist es nur ein GCC 2.95.4, da zum einen noch immer nicht alles so läuft, wie ich es gern hätte und zum anderen weil ich keine Zeit habe, auf GCC3 umzustellen.
Zitat:
Fakt ist, daß phase5 damals auf den Compiler gesetzt haben, der heute noch weiterentwickelt wird und auf das ABI, das auch in heutigen, noch weiterentwickelten Betriebssystemen verwendet wird.
Ich würde ja gerne mal hören, was einer damaligen glühensten Verfechter von WarpOS/StormC dazu zu sagen hat.
Zitat:
Während die Firma, die von neuen ppc-Erweiterungskarten bis hin zu einer ppc-Softwareflut alles versprochen hat,
An das Escena-G3 Board erinnert sich doch niemand mehr ;-)
Zitat:
Fakt ist, daß ich keine Wahl habe. Es gibt heute nur gcc und ich würde ihn gerne mit einer komfortablen IDE benutzen.
Er meinte, das es ein kommerzielle Compiler schwer hat, wenn gleichzeitig ein gleichwertiges kostenloses Produkt auf dem Markt ist.
Zitat:
Und es war H&Ps Entscheidung, ihn so zu patchen, daß es heute unmöglich ist, ihn zu benutzen. Benutzen heißt, ihn auch in einer aktuellen Version benutzen zu können, in der man in Entwicklerforen auch Hilfestellung bekommen kann.
Mit etwas gutem Willen könnte man das ARexx-Interface aus den StormGCC Quellen extrahieren und dann aktuellere Versionen benutzen, allerdings eben nicht für WarpOS.
Zitat:
IDEs auf allen anderen Plattformen machen es vor. Man kann einen C/C++ Compiler benutzen, ohne ihn patchen zu müssen. Und das hätten wir auch haben können, wenn nicht eine gewissen Firma diesen Grabenkrieg begonnen hätte, um sich selbst zu profilieren.
H&P hat einen IPC-Mechanismus eingebaut. Obs ohne gegangen wäre, kann ich nicht sagen.

[ Dieser Beitrag wurde von gni am 13.07.2005 um 09:14 Uhr editiert. ]
 
gni   Nutzer

12.07.2005, 16:46 Uhr

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

Zitat:
Solar:
Zitat:
gni:
Mein make macht das auch, oops :-P

:lach:
OK, ich gebe mich geschlagen...
8)

Ok, ich habe das "cd /usr/ports/lang/gcc[234][0-9]" vergessen ;-)
 
gni   Nutzer

12.07.2005, 16:32 Uhr

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

Zitat:
Solar:
Zitat:
gni:
Es geht auch mit einem stink-normalen make.

Ja, nur nehmen Dir oben genannte Beispiele sogar den Download der Sourcen ab.
Mein make macht das auch, oops :-P
Zitat:
Zitat:
Hast Du schon mal versucht ältere GCC Versionen mit einem aktuellen GCC zu übersetzen?
Nö. Ich habe keinen Bedarf für ältere GCC-Versionen. ;)
Es soll ja auch noch Rechner geben ohne mehrere GB Hauptspeicher und "langsamer" CPU. Da möchte man schlicht keine aktuellen GCC.
 
gni   Nutzer

12.07.2005, 15:42 Uhr

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

Zitat:
whose:
Du meinst unnötige Arbeit wie die Rücksichtnahme auf Gate-Funktionen bei 68K-Libraries mit PUP Unterstützung?

Gates haben auch WOS-Bibliotheken, die m68k-Applikationen transparent Zugriff auf den PPC gewähren.
Zitat:
Oder das üble Rumgetrickse mit CallHook()? Das braucht man bei WOS z.B. nicht.
-v bitte.
Zitat:
Unter anderem aufgrund zwar interessanter, aber eben nutzloser Grabenkriege, nicht nur zwischen WOS/PUP-Verfechtern.
Dieser Grabenkrieg wäre vermeidbar gewesen. Das Problem war nicht der Compiler.
 
 
Erste << 11 12 13 14 15 -16- 17 18 19 20 21 >> 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-2024 by amiga-news.de - alle Rechte vorbehalten.
.