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

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

1 -2- 3 4 5 6 7 >> Letzte Ergebnisse der Suche: 1106 Treffer (30 pro Seite)
gni   Nutzer

26.06.2008, 13:23 Uhr

[ - Direktlink - ] 		Thema: Booten mit USB-Stick
Brett: Amiga, AmigaOS 4

Zitat:
mboehmer:
Ist nach dem Booten das FlashROM der DENEB deaktiviert (showconfig oder Luciferin)?
Luciferin hat sich nicht über ein deaktiviertes Flashrom beschwert.
Zitat:
Hast du nach dem Update des Bootloaders das FlashROM mal komplett neu beschrieben, um Wechselwirkungen auszuschliessen?
Ich habe mehrfach geflasht. Zuerst alles geleert, dann Luciferin 4.0 neu gestartet. Da wurde das Flash als leer gezeigt. Danach habe ich mit 4.0 meine Config geflasht. Nach dem Booten kein USB, laut Luciferin war aber alles im Flashrom. Als Loader hatte ich die neue Variante mit RMB-NOLMB gewählt, sowohl mit als auch ohne Farbe. Weitere Experimente mit 4.0 wollte ich dann nicht mehr machen, deshalb bin ich dann zur funktionierenden 3.0 Variante zurückgegangen.

FYI, Poseidon manuell starten ging schief, weil meinem PsdStackloader das Execute-Bit fehlte, ich es ohne Pfadangabe aufrief und die Shell dann meinen alten PsdStackloader für die Highway benutzte (ja, der ist bei mir im Pfad). Das hat jetzt nichts mit dem Flashen zu tun, ist aber eventuell als Information für andere interessant, die Poseidon auch manuell starten wollen.
 
gni   Nutzer

26.06.2008, 08:11 Uhr

[ - Direktlink - ] 		Thema: Booten mit USB-Stick
Brett: Amiga, AmigaOS 4

Zitat:
mboehmer:
Hast du einen der neuen Bootloader von Chris aus dem Luciferin-Update installiert?

Bei mir scheinen die Loader von 4.0 nicht zu funktionieren. Poseidon wird nicht aktiviert. Mit Luciferin 3.0 und dessen Loader(n) ist USB nach dem Booten benutzbar.
 
gni   Nutzer

26.06.2008, 08:07 Uhr

[ - Direktlink - ] 		Thema: Booten mit USB-Stick
Brett: Amiga, AmigaOS 4

Zitat:
tploetz:
Es sind überhaupt keine Bootloader mehr im Verzeichnis Luciferin, warum sind die weg? Bei Version 3 waren sie noch da.
ReadMe und/oder Dokumentation lesen? Steht alles drin... Bei Luciferin 4.0 sind die Loader im Programm integriert.
 
gni   Nutzer

17.06.2008, 08:36 Uhr

[ - Direktlink - ] 		Thema: S: Highway
Brett: Kleinanzeigen (keine Auktionen!)

Ich habe sowohl eine Highway als auch eine AlgorPRO abzugeben.
 
gni   Nutzer

14.03.2008, 21:03 Uhr

[ - Direktlink - ] 		Thema: mit welchen compiler arbeitet ihr?
Brett: Programmierung

Zitat:
PeaBrain:
@der compiler geht durch und wenn er dann assemblieren will, gibs erst den fehler. linkerfehler schließe ich aus, daß der fehler was mit "in zeile ...." sagt.
Die präzisen Fehlermeldungen könnten helfen, eine Erklärung zu finden.
 
gni   Nutzer

27.02.2008, 08:50 Uhr

[ - Direktlink - ] 		Thema: Pic Viewer AGA / OS3.9
Brett: Amiga, AmigaOS 4

Zitat:
gerograph:
er brauch eine "tower.library"

FWIW, die tower.library und dessen JFIF.codec sind _veraltet_. Damit können keine progressiven JFIF Bilder dekodiert werden.
 
gni   Nutzer

25.02.2008, 12:45 Uhr

[ - Direktlink - ] 		Thema: Grösse Grafikkartenspeicher unter CGX erfragen
Brett: Programmierung

Zitat:
Wolfen:
Der Wert BoardSize wird bei einer Cybervision64 hier mit 64 MB angegeben, was natürlich falsch ist.
Da dieser Wert nichts mit dem Grafikspeicher der Karte zu tun hat, ist deine obige Aussage falsch.
 
gni   Nutzer

27.01.2008, 19:36 Uhr

[ - Direktlink - ] 		Thema: DosList Namen ?
Brett: Programmierung

Zitat:
Holger:
Der Grund liegt mehr darin, dass der BCPL-Code später durch C-Code ergänzt, bzw. komplett ersetzt wurde, und somit intern C-Routinen mit den Strings hantieren, von denen einige immer ein Null-Byte schreiben.
dol_Name ist _immer_ NUL-terminiert (sogar unter pre-2.0)! Falls der String nicht NUL-terminiert wäre, dann wäre dies vermutlich ein Bug.
 
gni   Nutzer

09.01.2008, 13:50 Uhr

[ - Direktlink - ] 		Thema: Sharing von PPC-Amigas übers Web
Brett: Programmierung

Zitat:
akl:
Die aktuelle Crosscompiler-Version ist AFAIR GCC 2.95.3-basiert (soweit ich weiss diese hier: http://www.zerohero.se/cross/mos.html).
Da auf der MOS Developer Site die diffs für den aktuellen MOS SDK GCC zu bekommen sind, kann man sich bei Bedarf selber einen Cross-Compiler erstellen. Derzeit wäre das sogar aktueller als alles Binär verfügbare.
Zitat:
Mit GCC 2.95.3 erhält man unter MOS-native in einer Reihe von Fällen jedoch stellenweise kaputten Code (je größer -On mit n>=0, desto größer die Wahrscheinlichkeit). Mit dem inoffiziellen GCC 2.95.4 verschwindet das Problem teilweise (IIRC diese hier: http://www.tbs-software.com/morgoth/projects.html).
AFAICT, zwischen 2.95.3 und 2.95.4 gibt es bei PPC keinen Unterschied was die Codegenerierung angeht. Zudem enthält der "offizielle" GCC für MOS mittlerweile fast alle relevanten Debian-Patches plus ein paar zusätzliche Korrekturen. Hast Du den aktuellen GCC (also die 2007-Release) von der MOS-Entwicklerseite mal getestet? IMHO ist diese Version sowohl dem 2.95.4 von Morgoth als auch den Cross-Compilern von Zerohero vorzuziehen. Hast Du außer -O<n> noch andere Flags verwendet? Wobei ich von n>2 immer abrate.
Zitat:
In mindestens einem Fall lag es jedoch unmittelbar an der Größe einer .c-Datei (in zwei Files gesplittet und Problem verschwunden), was ich doch recht seltsam finde.
Wie groß soll die denn gewesen sein? Wie hat sich der Fehler geäußert?
Zitat:
Weiterhin stehen auch noch mehrere libnix-Varianten mit unterschiedlichen Bugs zur Auswahl, von denen zumindest die neueste(?) offensichtlich nicht mehr kompatibel zu den vorherigen ist. Ixemul will ich gar nicht thematisieren.
Fehler in den Runtimes haben doch erstmal nicht direkt was mit dem GCC zu tun oder? libnix-Fehler haben auf den MOS-GCC auch keinen Einfluß, da dort (wie auch unter m68k) ixemul benutzt wird. Für libnix gab/gibt es doch immer mal wieder Updates. FWIW, was für Fehler sind denn im aktuellen MOS-libnix vorhanden?
Zitat:
Wer garantiert mir also, dass - wenn ich später denselben Source nochmal unter MOS-native compiliere - alles noch läuft, insbesondere wenn der MOS-native GCC vermutlich mit sich selbst compiliert worden ist und noch mutmassliche Ixemul-Bugs mitschleift?
AFAIK, Unterschiede in der Codegenerierung bei gleicher Compilerversion habe ich nur bei Floats gesehen und das war auf einer Alpha mit einem m68k-Crosscompiler. Ansonsten konnte ich nie einen Unterschied feststellen (und ich benutze häufig Crosscompiler). IMHO ist es eher unwahrscheinlich, das Fehler der Runtime Auswirkungen auf die Codegenerierung haben. Und nur zu Info: der MOS-native GCC auf der Entwicklerseite wurde nicht unter MOS erstellt. Die aktuellen Archive wurden alle unter FreeBSD per Cross-Compiler erstellt und anschließend kurz "getestet", dh. es wurde eine HelloWorld.c übersetzt und ausgeführt.
Zitat:
Oder umgekehrt, wenn es nicht läuft, compiliere ich dann alles nochmal lokal um zu sehen ob es dann geht?
Das sollte keinen Unterschied machen.
Zitat:
Vielleicht bin ich altmodisch, aber für Entwicklung "zuhause" möchte ich gerne ein SDK was auf dem Target out-of-the-box fehlerfrei läuft mit einer stabilen und abwärtskompatiblen C-Library, die bei Bedarf (notfalls externe Semaphore und nur selektive Verwendung von Funktionen) auch in einer Library läuft.
Ich hatte weder unter m68k noch unter MOS jemals Stabilitätsprobleme mit dem GCC und ich habe wirklich viele GCC-Versionen benutzt. Auch ixemul hat mir als GCC-Runtime nie Instabilitäten verursacht, aber eventuell habe ich es auch nur nie bemerkt? ;-) Was die Verwendung von Funktionen der C-Standardbibliothek in Amiga-Shared-Libraries angeht, bin ich allerdings anderer Ansicht. Nur sehr wenige Funktionen können wirklich problemlos in einen solchen Bibliothek verwendet werden. Und Semaphoren möchte ich da schon gar nicht sehen.
Zitat:
Am Besten ein aktueller GCC (4er-Serie) mit AltiVec-Support (nicht nur im Compiler sondern auch in der ABI bzw. im Exec).
Ich kann die Qualität des GCC nach 2.95.x nicht wirklich beurteilen. Ich kenne da nur die Aussagen des MOS-Teams. Dennoch habe auch mit GCC3 bzw GCC4 PowerUP-Programme erstellt und die haben dann auch funktioniert (zb. mpega_libmad oder xpkGZIP).
 
gni   Nutzer

07.01.2008, 10:26 Uhr

[ - Direktlink - ] 		Thema: Sharing von PPC-Amigas übers Web
Brett: Programmierung

Zitat:
akl:
@p-OS:
Auf Crosscompiler würde ich mich nicht unbedingt verlassen wollen (z.B. MOS SDK).
Könntest Du das bitte etwas konkreter ausführen?
 
gni   Nutzer

21.12.2007, 16:49 Uhr

[ - Direktlink - ] 		Thema: WarpOS Target für GCC
Brett: Programmierung

Zitat:
Chritoph:
Zitat:
gni:
Taugt aber eh nix und ist auch nur GCC 2.95.x oder sogar noch was älteres (EGCS).
EGCS 1.1.2 = GCC 2.91.66 oder so ähnlich.
Sag ich doch - uralt.
Zitat:
Mittlerweile hab ich den Kram gefunden - binär. Das hilft beim CrossCompiler basteln leider nur begrenzt, aber ich bin noch nicht am Ende mit meinem Latein.
FYI, vor StormGCC gab es nie einen GCC mit WOS als Target. Alle früheren WOS-Compiler sind ELF-Compilern mit SYSV V4 ABI, die mittels Hacks (spezielle LP-Makros und einem Postprocessor) WOS-tauglich gemacht wurden. Soll heissen, wenn Du die Quellen für diese Versionen suchst, mußt Du entweder die alten Amiga-Patches für 2.95.x nehmen oder mit ppc-linux konfigurieren (AFAIR, dieses Target hat Paladin damals für "seinen" GCC benutzt).
Zitat:
Zitat:
Was war so enttäuschend [bei StormGCC]? Einen "besseren" C++ Compiler für WOS wirst Du nicht finden.
Zumindest auf meiner Original-CD sind includes nicht okay, Pfade werden falsch gesetzt, die IDE schneckt und der Compiler rennt auch nicht gerade.
Du solltest keine Wunder vom PPC erwarten. Im Vergleich zu 68k sollte StormGCC auf PPC aber dennoch spürbar schneller sein. Der GCC ist träge (mit neueren Versionen wurde das noch schlimmer) und die PPC-Compiler sind größer (==langsamer), da der GCC einen Haufen von Prozessoren bei PPC unterstützt, von denen die meisten nie verwendet werden (der Compiler soll halt out-of-the-box für alles verwendet werden können, ohne eine weitere Version installieren zu müssen).
Zitat:
Die entstehenden Binaries sind ganz okay, aber die IDE vermurkst meine Compilerargumente immer wieder. Klar könnte man den Compiler mit makefiles dressieren, dann ist die usability vielleicht gewohnter. Aber das macht den Compiler auch nicht schneller.
Das Makefile hätte auch den Vorteil für Cross-Übersetzungen ;-)
Zitat:
Soweit ich sagen kann war ich beim bauen der StormC-Quellen unter Linux relativ erfolgreich. Aber es fehlt noch so eingiges, bis man das wirklich nutzen kann.
Assembler, Linker, Includes, libc? ;-)
Zitat:
Ich werde wohl den Weg weiter verfolgen, da der WarpGCC auch nicht neuer als 2.95 wäre.
Vorallem wäre es kein echter WarpOS-ABI kompatibler Compiler. Sowas bekommst Du nur mit StormGCC, aber auch da gibt es keine vollständige WarpOS ABI-Kompatibilität (ja, da ist H&P von seinem eigenen Standard abgewichen!).

PS: Du solltest versuchen mit weniger Returns zu arbeiten. Die Forumsoftware arbeitet wie ein Textprogramm, dh. das Layout innerhalb eines Absatzes wird dynamisch gemacht. Ein echtes Return brauchts Du nur wenn, Du einen neuen Absatz beginnen möchtest.
 
gni   Nutzer

21.12.2007, 15:02 Uhr

[ - Direktlink - ] 		Thema: WarpOS Target für GCC
Brett: Programmierung

Zitat:
Andreas_Wolf:
> Vor langer Zeit habe ich diesen Hack mal runtergeladen, aber ich weis
> weder wo noch den Ort, wo das Archiv abgeblieben ist.
http://web.archive.org/web/20031011180423/http://www.kolumbus.fi/jami.laakkonen/ppc/
Meinst du das?
Möglicherweise habe ich da etwas verwechselt... Ich glaube ich meinte einen 2.95.3 für MOS mit AmigaOS/m68k als Host, das Archiv war von Jens Langner. Das ist natürlich was ganz anderes.
 
gni   Nutzer

20.12.2007, 19:51 Uhr

[ - Direktlink - ] 		Thema: OS4 Progamm mit vbcc
Brett: Programmierung

Zitat:
MaikG:
assign vincludeos4: vbcc:targets/ppc-amigaos/include
assign vincludeos4: vbcc:Includes
assign vlibos4: vbcc:targets/ppc-amigaos/lib
Da fehlt wieder mal ein ADD
Zitat:
In vbcc:Includes/ hab ich das OS4 zeugs kopiert.
 
gni   Nutzer

20.12.2007, 19:46 Uhr

[ - Direktlink - ] 		Thema: WarpOS Target für GCC
Brett: Programmierung

Zitat:
Chritoph:
Vielleicht sind meine Suchworte schlecht, aber ich find nischt.
Vor langer Zeit habe ich diesen Hack mal runtergeladen, aber ich weis weder wo noch den Ort, wo das Archiv abgeblieben ist. Taugt aber eh nix und ist auch nur GCC 2.95.x oder sogar noch was älteres (EGCS).

Zitat:
Wie gut oder schlecht der ist würd ich halt selber gerne ausprobieren. Denn...
Zitat:
Wenn es nicht C++ sein muß, nimm VBCC. Der unterstützt WOS vorbildlich.
C++ ist der Plan. VBCC tut super, keine Frage, aber ist eben "nur" C.
C++ ist eh überschätzt ;)

Zitat:
Die Quellen [von StormGCC] gibt es auch z.B. von H&P, sind aber mit Vorsicht zu genießen. Zum Einen ist das ein etwas antiquierter GCC 2.94irgendwas, zum anderen war ich schon mit den Ergebnissen des StormC4/GCC nicht zufrieden.
Was Neueres als 2.95.x für WOS wird es vermutlich nie geben, da sich die Struktur des GCC ab 3.x stark geändert hat, so daß sich die Patches von 2.95.x nur mit sehr viel Aufwand anpassen lassen. Da WOS nun nicht gerade ein noch sehr aktives Target ist, stehen die Chancen für eine neuere GCC Version eher schlecht.
Allerdings gäbe es neuere GCC Versionen mit PowerUP als Target *g*

Zitat:
Ich war ziemlich enttäuscht, als ich den gekauft und ausprobiert habe.
Was war so enttäuschend? Einen "besseren" C++ Compiler für WOS wirst Du nicht finden.

Zitat:
H&P hat da auch ziemlich wild herumgepatcht und einen Zwitter aus POSIX und Amiga Programm gebastelt. Es kompiliert unter Linux, aber nach Blick in die Sourcen bin ich nicht so recht überzeugt davon, diesen Weg weiter zu verfolgen.
Du hast die StormGCC Quellen unter _Linux_ übersetzen können? Respekt! Als ich die Quellen gesichtet habe, war ich von Teilen der H&P Änderungen entsetzt. Warum vermischt man portablem Code mit Amigafunktionen? Wollte man damit das Nutzen der Quellen erschweren? Andererseits ist der Kern des Ports brauchbar, hätte mit ein klein wenig mehr Aufwand Storm3 kompatibel sein können und 16Bit-Alignment in Strukturen (wegen 68k) war auch keine kluge Entscheidung.
 
gni   Nutzer

19.12.2007, 08:35 Uhr

[ - Direktlink - ] 		Thema: WarpOS Target für GCC
Brett: Programmierung

Zitat:
Chritoph:
CC = ppc-amigaos-gcc -warpup ...

Das ist genau was ich suche! Ein GCC der schön brav WarpOS binaries
ausspuckt. Ich will das! Wo kriegt man das?
Vermutlich im Aminet. Aber diese Version will man eigentlich nicht, da sie nichts taugt. Wie der Name bereits sagt, ist das ein Compiler für PowerUP, der mit Hacks dazugebracht wurde, ELF-Programme WarpOS tauglich zu machen. Wenn es nicht C++ sein muß, nimm VBCC. Der unterstützt WOS vorbildlich.

Zitat:
Ich würd mir das ja selber schreiben, aber ich vermute mal, dass ich da Jahre beschäftigt bin.

GCC kompilieren ist nicht das Problem.
Nur weil Du den GCC kompilieren kannst, ist die Erstellung eines WOS-Targets noch lange nicht in Reichweite. Auch wenn das schon mal ein Anfang ist :)

Zitat:
Gibt es irgendwo eine entsprechendes WarpOS-Target für GCC zu bekommen?
Im Aminet sind(waren?) die Quellen für StormGCC. Allerdings sind diese nicht wirklich brauchbar...
 
gni   Nutzer

31.08.2007, 08:51 Uhr

[ - Direktlink - ] 		Thema: Welche lha Version?
Brett: Amiga, AmigaOS 4

Zitat:
GREX:
Könnte es zum Beispiel sein, dass die Lha-Executables aus dem Aminet schneller als OS3.9-Unarc (Xadmaster) sind, welches ich normale verwende?
Das eigenständige (Amiga-)LhA ist definitiv schneller als xadmaster.libbrary basierte Entpacker.
 
gni   Nutzer

19.06.2007, 11:01 Uhr

[ - Direktlink - ] 		Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

Zitat:
Reth:
Zitat:
gni:
AFAIR, GCC 3.3 hatte noch eine eigene c++filt Version.
Die ist leider nirgends auffindbar.
Wenn Du den den OS4 GCC installiert hast, dann kannst Du auch dessen c++filt verwenden (das ist das c++filt der ppc-amigaos binutils).
Zitat:
D.h., man braucht 3.3er binutils für 68k.
So etwas gibt es nicht. Die binutils sind erst bei Version 2, zb. 2.16 ;-)
Zitat:
Gehen auch neuere Versionen, d.h. sind die binutils abwärtskompatibel?
Genau wie beim GCC braucht man für m68k-amigaos nutzbare binutils diffs. Solche diffs sind für 2.9.1 (dem defacto Standard für m68k-amigaos) verfügbar. Eine neuere binutils Version (2.14) mit m68k-amigaos Support ist im adtools Repository zu finden. Die könnte man verwenden, dh. ja binutils sind abwärtskompatibel. Die üblicherweise verwendete Version ist aber 2.9.1 und bei der Version solltest Du auch besser bleiben.
 
gni   Nutzer

19.06.2007, 10:49 Uhr

[ - Direktlink - ] 		Thema: GCC X-Compiler AOS4 -> AOS3.x
Brett: Programmierung

Zitat:
Reth:
Das verstehe ich nicht, zumindest nicht im Zshg. mit dem Posting von Jörg auf UtilityBase:

"The sources, or rather diffs to the original sources, were always included in GeekGadgets:
ftp://back2roots.org/pub/geekgadgets/amiga/m68k/alpha/gcc/
In dem Verzeichnis sind die Änderungen des m68k-amigaos Ports für die originalen GCC Quellen zu finden.
Zitat:
But you can't build PPC native executables from them without completing the OS4 port of ixemul.library first, the current one can only be used for running m68k ixemul software on OS4."
AFAICT, das ist falsch. Für gehostete Compiler wird ixemul nicht gebraucht.
Zitat:
Dann sagt er noch:

"To build a ppc-amigaos hosted, m68k-amigaos target cross compiler you'd have to merge the host parts of the adtools GCC with the target parts of the GeekGadgets GCC."

Sind das nun 2 versch. Möglichkeiten, die theoretisch zu einem AOS4-hosted 68k-X-GCC führen, oder müssen beide Bedingungen erfüllt sein?
Wie er schrieb, Du brauchst die m68k-amigaos diffs *und* den host Anteil für OS4 aus dem adtools Repository, damit Cross-Compiler mit OS4 als Host überhaupt gebaut werden können und der Compiler unter OS4 auch seinen Dienst tut. Die m68k-amigaos diffs (und die originalen GCC Quellen) kennen OS4 nicht und deswegen muß man das "nachrüsten".
Auf Deinem Buildsystem brauchst Du dann noch einen Cross-Compiler für OS4 und einen für m68k-amigaos, damit am Ende ein unter OS4 gehosteter Cross-Compiler rauskommt. Dieses Vorgehen nennt sich Canadian-Cross.
 
gni   Nutzer

19.06.2007, 09:00 Uhr

[ - Direktlink - ] 		Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

Zitat:
Reth:
Bin gerade im Durchsuchen der GoldED-CD und der Updates, ob da ein neueres dabei ist!

Also weder bei GoldED AIX noch beim Cubic-Demo ist der Demangler beim GCC 3.3 dabei.
AFAIR, GCC 3.3 hatte noch eine eigene c++filt Version.
Zitat:
Entweder gibts den dann gar nicht für AmigaOS, oder die GoldED-/Cubic-Distris haben hier nen Fehler?!
FYI, c++filt war ursprünglich Bestandteil der binutils und des GCC. Irgendwann haben die GCC Entwickler aber entschieden, das eine Version reicht und c++filt aus dem GCC Archiv entfernt. Die GCC Entwickler gingen vermutlich davon aus, das immer brandaktuelle binutils verwendet werden :-/
 
gni   Nutzer

19.06.2007, 08:54 Uhr

[ - Direktlink - ] 		Thema: GCC X-Compiler AOS4 -> AOS3.x
Brett: Programmierung

Zitat:
Reth:
Zitat:
gni:
Und was ist an der Information nun neu? Genau _das_ hatte ich Dir bereits gesagt!
Dann hatte ich Deinen Bezug zur ixemul.library entweder überlesen oder falsch verstanden!
Die ixemul unter OS4 hat mit Deinem Anliegen *nichts* zu tun. Nochmal: der OS4 GCC unter OS4 benötigt keine ixemul. Damit benötigen andere unter OS4 _gehostete_ GCC Versionen auch keine ixemul. Für den Rest siehe frühere Postings hier und auf utilitybase.com.
 
gni   Nutzer

18.06.2007, 16:35 Uhr

[ - Direktlink - ] 		Thema: GCC X-Compiler AOS4 -> AOS3.x
Brett: Programmierung

Zitat:
Reth:
In meiner Nachfrage hier:
Utility Base
wurde auf meine in diesem Forum gestellte Frage geantwortet, ob man einen Teil der GCC-Installation von AOS4 nach GCC 3.3 68k kopieren kann, damit das Ganze schneller läuft.

Kann mir hier evtl. jmd. sagen, welche Teile ich alle gefahrlos kopieren kann?

Denke da an so Sachen aus dem bin-Verzeichnis wie c++, c++filt, cpp, g++, gcc!
Nichts! Und damit solltest Du dieses Unterfangen auch besser beenden.
 
gni   Nutzer

18.06.2007, 16:27 Uhr

[ - Direktlink - ] 		Thema: GCC X-Compiler AOS4 -> AOS3.x
Brett: Programmierung

Zitat:
Reth:Sigbjørn Skjæret [MOS-X-GCC], siehe dazu entsprechenden Aminet-Upload!
Du hast einen eklatanten Denkfehler. Du kannst nicht von einem Cross-Compiler unter System X auf einen Cross-Compiler unter System Y schließen! Der Compiler benutzt immer die Umgebung des Hostsystem, egal wie die aussieht. Der GCC fühlt sich am wohlsten mit UN*X als Host. Es geht aber auch anders, wie der OS4 GCC zeigt.
Zitat:
Zitat:
Suchen hilft.
Hab ich gemacht, daher diese Aussage (bin leider nicht fündig geworden, abgesehen von den bereits angegebenen Sourcen im Aminet etc.)!
Mittlerweile solltest Du die diffs gefunden haben.
Zitat:
Zudem wird für eine Erstellung eines AOS4-68k-X-Compilers unter AOS4 zuerst eine vollständige ixemul.library (laut Aussage des Autors derselben) benötigt
Und was ist an der Information nun neu? Genau _das_ hatte ich Dir bereits gesagt!
Zitat:
(die es laut Aussage desselben Autors für MOS anscheinend gibt)!
Richtig, für MOS gibt es eine funktionierende ixemul. Ohne die ist der native GCC dort aber auch nicht benutzbar. Das ist jedoch eine ganz andere Situation als unter OS4. Die OS4-Entwickler haben sich _bewußt_ gegen die ixemul entschieden, das sie die ixemul als "Fremkörper" betrachten. Den GCC nativ unter OS4 zu bauen stand dort vermutlich nie zu Debattte. Unter MOS ist es prinzipiell möglich den GCC zu bauen, ob es gemacht wurde/wird, ist mir nicht bekannt. Die aktuellen Version von binutils und GCC des MOS-SDK wurden jedoch mit einem _Cross-Compiler_ erstellt. Und das ist auch für unter OS4 gehostete Cross-Compiler möglich. Was Du dafür brauchst, hat Joerg Strohmayer in seiner ersten Antwort auf utilitybase.com geschrieben, die Du allen Anschein nach nicht verstanden hast. Was Du willst läßt sich nur mit einem Canadian-Cross Build lösen und sowas ist _nichts_ für GCC-Anfänger. Zumal Du für OS4 als Host Dir auch noch die entsprechenden diffs aus dem adtools Projekt besorgen mußt.
 
gni   Nutzer

18.06.2007, 14:59 Uhr

[ - Direktlink - ] 		Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

Zitat:
Reth:
Ich verwende doch den GCC3.3 aus GoldED AIX und der ist 68k und erstellt 68k. Zudem zeigen auch alle Pfade, Assigns etc. auf diese GCC-Installation, so dass auch dessen c++filt genommen wird (werde das nochmal nachprüfen, so das überhaupt geht).
Der Pfad ist wichtig, denn ansonsten kann ein x-beliebiges c++filt Verwendung finden. Da Du unter OS4 arbeitest, ging ich davon aus, das Du auch den OS4 GCC installiert hast und dessen c++filt verwendest.
Zitat:
Von daher müsste der _ eigentlich verwendet werden, ich probiers aber mal ohne
Verwendet wird das zuerst gefundene Programm. FWIW, es könnte auch sein, das das c++filt zu alt ist, dh. die Version des GCC 2.95.x kann keine Symbole des GCC3 dekodieren.
Zitat:
(muss c++filt nicht wissen, wo die entsprechende Objektdatei liegt?
c++filt dekodiert nur Symbole, die Du Ihm vorwirfst. Mit Objektdateien kann es nicht umgehen.
 
gni   Nutzer

18.06.2007, 09:39 Uhr

[ - Direktlink - ] 		Thema: Execute und input/output
Brett: Programmierung

Zitat:
ZeroG:
Weiß zwar nicht wie das unter Aros ist aber unter OS4 leitet man die Ausgaben von GCC so um:
gcc -o test test.c *>< >compile.log
"*>" ist eine mit der Shell V45 eingeführte Neuerung: damit kann stderr umgeleitet werden.
 
gni   Nutzer

11.06.2007, 10:32 Uhr

[ - Direktlink - ] 		Thema: MorphOS PowerUp startet nicht auf A4k (schwarzer Bildschirm)
Brett: MorphOS

Zitat:
aPEX:
Ich gebs auf... Habe glaub jetzt so ziemlich jeden Tip (bis auf Karten ausbauen usw.) ausprobiert und komme einfach nicht weiter.
Ignoranz ist selten hilfreich...
 
gni   Nutzer

11.06.2007, 10:29 Uhr

[ - Direktlink - ] 		Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

Zitat:
Reth:
code:
echo "_ZN13FrameFactoryC6framesE" | c++filt
bekomme ich nur gesagt:
code:
_ZN13FrameFactoryC6framesE
Das hilft nicht wirklich.
Du mußt schon das passende c++filt verwenden oder wissen wie Symbole in Objektdateien aufgebaut sind. FYI, ELF verwendet keine Unterstriche. Versuch es also mal ohne den Unterstrich.
Zitat:
Und erst ein GCC-Studium und eines über Objektdateien und Linker möchte ich mir nicht antun, "nur" um ein wenig C/C++ zu programmieren!
Was hat die Verwendung von -Wl,... mit einem Studium zu tun? Vorgekaut wird nichts, Du mußt Dich schon selber bemühen.
 
gni   Nutzer

11.06.2007, 10:20 Uhr

[ - Direktlink - ] 		Thema: GCC X-Compiler AOS4 -> AOS3.x
Brett: Programmierung

Zitat:
Reth:
Vllt. frag ich noch den Autor des MOS-X-GCC.
Was/wer genau soll das sein?
Zitat:
Er hat schon ein paar Mal probiert so einen X-Compiler zu erstellen, ist aber bisher immer gescheitert und hat auch noch keine Lösung für dieses Problem.
Woran ist er gescheitert? Einen Crosscompiler für m68k-amigaos zu bauen, der nativ unter OS4 läuft? Das hatten wir doch bereits durchgekaut... Compiler für OS4 als Host können (derzeit) nur per Crosscompiler selbst gebaut werden, dh. unter einem UN*X System.
Zitat:
Ich weiss ja nicht einmal, woher ich die Sourcen eines 68k GCC (> als 2.7.2, die gibts im Aminet) bekommen kann!
Suchen hilft.
 
gni   Nutzer

11.06.2007, 10:15 Uhr

[ - Direktlink - ] 		Thema: GCC X-Compiler AOS4 -> AOS3.x
Brett: Programmierung

Zitat:
Reth:
GeekGadgets gibts ja auch nicht mehr, so dass ich nicht einmal weiss, wo man denn nun die Sourcen eines AOS-68k-GCC herbekommen könnte.
Das ftp-Archiv ist immer noch verfügbar, zb. bei back2roots.org
 
gni   Nutzer

30.05.2007, 12:20 Uhr

[ - Direktlink - ] 		Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

Zitat:
Heisst das, ich kann beim entsprechenden Linkaufruf des g++ einfach den Parameter -C mitgeben (oder wie muss ich das nm verstehen)?
nm ist ein separates Tool, das Dir Sybolinformationen zu einem Objektfile gibt. Mit dem Linker hat das nichts zu tun. Eventuell funktioniert folgendes als Option beim Linken: -Wl,--demangle
 
gni   Nutzer

25.05.2007, 12:31 Uhr

[ - Direktlink - ] 		Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung

Zitat:
Solar:
Rückgängig machen kann man [kryptische Namen] mit c++filt
AFAIK, "moderne" Linker machen diese Dekodierung von sich aus. Mit der Option -C zu nm kann man eine Liste mit dekodierten Namen der Symbole eines Objektfiles bekommen.
Zitat:
code:
$ echo "_ZN13FrameFactoryC14createAddFrameEiiiPhS0_PK6BitMap" | c++filt
Das geht auch ohne echo .-)
 
 
1 -2- 3 4 5 6 7 >> 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.
.