ENGLISH VERSION |
|
Links | | | Forum | | | Kommentare | | | News melden |
Chat | | | Umfragen | | | Newsticker | | | Archiv |
amiga-news.de Forum > Suche | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
||||||
Reth
Nutzer
29.05.2007, 12:33 Uhr [ - Direktlink - ] |
Thema: YAM2.4 auf 2.5 - Welche Konfig-Dateien übenehmen?
Brett: Amiga, AmigaOS 4 Hallo Thomas, danke für die Antwort! Zitat: Nach einem Standalone-Start von 2.5 fand ich im YAM-Verzeichnis nicht so viele .xyz-Dateien wie im 2.4er, dachte daher, dass ich nicht alle diese Dateien (die mit Punkt beginnen) übernehmen muss. Zitat: Hab bei mir beide Installationen getrennt, muss daher "nur" die Mailordner sichern. Zitat: Hi, so hab ich die Klassen auch zusammenbekommen. Würd mich mal interessieren, ob bzw. wie ich das TextEditor-Teil mit IBrowse verwenden kann. Hab das Gefühl, dass das Eingabefeld, welches ich hier gerade mit IBrowse für die Antwort nehme kein TextEditor.mcc ist. Aber das ist ein anderes Thema. Ciao |
|||||
Reth
Nutzer
29.05.2007, 10:55 Uhr [ - Direktlink - ] |
Thema: YAM2.4 auf 2.5 - Welche Konfig-Dateien übenehmen?
Brett: Amiga, AmigaOS 4 Hallo allerseits, habe mir mal für AOS4 YAM2.5 installiert und wollte nun wissen, welche der Konfig-Dateien (.xyz) ich aus der 2.4er Version übernehmen kann? Vielen Dank schon mal! Ciao |
|||||
Reth
Nutzer
24.05.2007, 21:09 Uhr [ - Direktlink - ] |
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung Vielen Dank für eure Tips! Hier mal ein Compileraufrufbsp. der Aufruf zum Linken (makefile macht wohl weniger Sinn, ist eh eins von GoldED, das dann nicht die Compilerparameter direkt enthält!). Was bei mir auch noch der Fall ist: Nicht alle Klassen des Projektes sind im makefile drinne und es klappte unter 2.95.3 dennoch immer! Z.B. fehlt die statische Klasse FrameFactory komplett, liegts evtl. daran? Das mit dem fehlenden Main hab ich inzwischen lokalisiert! Ist noch ein fehlender Teil der Umstrukturierung, es gibt wirklich noch kein main()! Eine weitere Frage nochmal: Wie erkenne ich denn nun aus den Linkerfehlern, was ihm fehlt!? Compilerbsp.: g++ -noixemul -c -o o/gcc-classic/GadgetMessageReceiverC.o GadgetMessageReceiverC.cc Linken: g++ o/gcc-classic/ScreenModeRequestC.o o/gcc-classic/ScreenModeHookC.o o/gcc-classic/ResourceC.o o/gcc-classic/GadgetC.o o/gcc-classic/ImageButtonC.o o/gcc-classic/PointC.o o/gcc-classic/HexManagerC.o o/gcc-classic/PlayerC.o o/gcc-classic/PlayerManagerC.o o/gcc-classic/HexagonC.o o/gcc-classic/FrameC.o o/gcc-classic/EdgeC.o o/gcc-classic/BuildingC.o o/gcc-classic/AnimObjectManagerC.o o/gcc-classic/AnimObjectC.o o/gcc-classic/AnimationC.o o/gcc-classic/MenuSeperatorC.o o/gcc-classic/MenusC.o o/gcc-classic/MenuC.o o/gcc-classic/MenuItemC.o o/gcc-classic/MenuEntryC.o o/gcc-classic/ScreenC.o o/gcc-classic/RastPortC.o o/gcc-classic/WindowC.o o/gcc-classic/WizardGroundsC.o o/gcc-classic/ActivityC.o o/gcc-classic/QuitActivityC.o o/gcc-classic/IntuiTickActivityC.o o/gcc-classic/ClickHandlerC.o o/gcc-classic/TowerGadgetActivityC.o o/gcc-classic/ApplicationC.o o/gcc-classic/GUIApplicationC.o o/gcc-classic/MessageC.o o/gcc-classic/IntuiMessageC.o o/gcc-classic/IntuiMessageReceiverC.o o/gcc-classic/MenuMessageReceiverC.o o/gcc-classic/GadgetMessageReceiverC.o -noixemul -o bin/gcc-classic/WizardWars Ciao |
|||||
Reth
Nutzer
24.05.2007, 09:35 Uhr [ - Direktlink - ] |
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung @Solar: Danke für die Tips! Werde versuchen heute Abend mal mein makefile zu posten. Gibt es denn irgendwo aussagekräftige Beschreibungen zu diesen Linkerfehlern? Ciao |
|||||
Reth
Nutzer
24.05.2007, 00:09 Uhr [ - Direktlink - ] |
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung So nun kam das Unvermeidliche: Nachdem alles angepasst wurde, so dass der GCC 3.3 durchkompiliert, kommen nun die Linkerfehler (mit denen ich noch nie was anfangen konnte! Gibts dazu irgendwo ne hilfreiche Doku oder so?): code:/gg/lib/gcc-lib/m68k-amigaos/3.3/../../../libnix/ncrt0.o(.text+0x60): undefined reference to 'main' o/gcc-classic/AnimObjectManagerC.o(.text+0x16): undefined reference to '_ZN18AnimObjectManagerC10allObjectsE' o/gcc-classic/AnimObjectManagerC.o(.text+0x28): undefined reference to '_ZN18AnimObjectManagerC10allObjectsE' o/gcc-classic/AnimObjectManagerC.o(.text+0x118): undefined reference to '_ZN18AnimObjectManagerC10allObjectsE' o/gcc-classic/AnimObjectManagerC.o(.text+0x12c): undefined reference to '_ZN18AnimObjectManagerC10allObjectsE' o/gcc-classic/AnimObjectManagerC.o(.text+0x13e): undefined reference to '_ZN18AnimObjectManagerC10allObjectsE' o/gcc-classic/AnimObjectManagerC.o(.text+0x22e): more undefined references to '_ZN18AnimObjectManagerC10allObjectsE' follow o/gcc-classic/WizardGroundsC.o(.text+0xe62): undefined reference to '_ZN13FrameFactoryC14createAddFrameEiiiPhS0_PK6BitMap' o/gcc-classic/WizardGroundsC.o(.text+0xe94): undefined reference to '_ZN13FrameFactoryC14createAddFrameEiiiPhS0_PK6BitMap' o/gcc-classic/WizardGroundsC.o(.text+0xec6): undefined reference to '_ZN13FrameFactoryC14createAddFrameEiiiPhS0_PK6BitMap' o/gcc-classic/WizardGroundsC.o(.text+0xef8): undefined reference to '_ZN13FrameFactoryC14createAddFrameEiiiPhS0_PK6BitMap' o/gcc-classic/WizardGroundsC.o(.text+0xf2a): undefined reference to '_ZN13FrameFactoryC14createAddFrameEiiiPhS0_PK6BitMap' o/gcc-classic/WizardGroundsC.o(.text+0xf5a): more undefined references to '_ZN13FrameFactoryC14createAddFrameEiiiPhS0_PK6BitMap' follow o/gcc-classic/WizardGroundsC.o(.text+0x1256): undefined reference to '_ZN13FrameFactoryC9getFramesEi' o/gcc-classic/WizardGroundsC.o(.text+0x1282): undefined reference to '_ZN13FrameFactoryC9getFramesEi' o/gcc-classic/WizardGroundsC.o(.text+0x17ec): undefined reference to '_ZN13FrameFactoryC9getFramesEi' o/gcc-classic/WizardGroundsC.o(.text+0x1844): undefined reference to '_ZN13FrameFactoryC9getFramesEi' o/gcc-classic/WizardGroundsC.o(.text+0x189e): undefined reference to '_ZN13FrameFactoryC9getFramesEi' o/gcc-classic/WizardGroundsC.o(.text+0x18f8): more undefined references to '_ZN13FrameFactoryC9getFramesEi' follow /gg/lib/gcc-lib/m68k-amigaos/3.3/../../../libstdc++.a(basic_file.o)(.text+0x286): undefined reference to 'getc' /gg/lib/gcc-lib/m68k-amigaos/3.3/../../../libstdc++.a(basic_file.o)(.text+0x242): undefined reference to 'fdopen' collect2: ld returned 1 exit status AnimObjectManger und FrameFactory sind statische Klassen von mir, die anderen Fehler sind wohl auf irgendwelche Includes zurückzuführen. allObjects sind im AnimObjectManger als private deklariert: C++ code:createAddFrame sieht im FrameManger wie folgt aus:static std::map<const int, std::vector<AnimObjectC *> > allObjects; C++ code:static void createAddFrame(const int type, int width, int height, PLANEPTR data, PLANEPTR mask=NULL, const struct BitMap * const friendBitMap=NULL); Bei Bedarf kann ich auch noch mehr Code posten (z.B. verwendende Stellen, die Implementierungen an sich und was noch gewünscht ist)! Kann mir hier bitte jmd. weiterhelfen, da ich aus den Fehlermeldungen absolut nicht schlau werde! Vielen Dank schon einmal! Ciao |
|||||
Reth
Nutzer
23.05.2007, 22:39 Uhr [ - Direktlink - ] |
Thema: MorphOS PowerUp startet nicht auf A4k (schwarzer Bildschirm)
Brett: MorphOS @aPEX: Hi, konnte Dir mein damaliger Thread hier auch nicht helfen? http://www.pegasosforum.de/viewtopic.php?t=2557&postdays=0&postorder=asc&start=0 Die auf Morphzone hab ich leider nicht rausgesucht! Hab auch die MOS-Installation leider nicht mehr. Ciao |
|||||
Reth
Nutzer
17.05.2007, 21:35 Uhr [ - Direktlink - ] |
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung Ok, der Namespace für slist ist: __gnu_cxx Hab im Include geschaut und den ersten einfach probiert! |
|||||
Reth
Nutzer
16.05.2007, 22:10 Uhr [ - Direktlink - ] |
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung Zitat: Also <slist.h> liefert ne deprecated Warnung, <ext/slist> tut, also fast, denn nun bekomm ich die Meldung: error: 'slist' is used as a type, but is not defined as a type wenn ich Variablen als slist-Typen deklariere wie z.B.: C++ code:slist<struct TagItem> tagItems; Wie bekomm ich denn den Namespace raus, der hier verwendet werden muss? std ists ja nicht, ist es ext? Ciao |
|||||
Reth
Nutzer
16.05.2007, 12:53 Uhr [ - Direktlink - ] |
Thema: Was ist ein AmigaOne im Detail?
Brett: Amiga, AmigaOS 4 Mal meine Antwort zum Thread-Thema: Etwas, das niemand hat! |
|||||
Reth
Nutzer
16.05.2007, 09:48 Uhr [ - Direktlink - ] |
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung Hallo gni! Zitat:Danke! Wollte aber eh auf dem 3.3er bleiben, wenn ichs mal migriert habe! Liegt der andere Include-Ort von slist daran, dass es nicht in den Standard übernommen wurde? Zitat: Brauche in dieser Klasse Funktionen aus beiden Includes, werde daher wohl auch beide einbinden, also <string> und <cstring>, um sicher zu gehen, dass es überall klappt. Ciao |
|||||
Reth
Nutzer
15.05.2007, 21:13 Uhr [ - Direktlink - ] |
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung @gni: Zitat:Bei: C++ code:Bekomme ich aber gesagt:#include <slist> code:slist: No such file or directory @Holger: Zitat: Hm bei mir hat hier wohl ein: C++ code:gelangt!?#include <string> Ciao |
|||||
Reth
Nutzer
14.05.2007, 23:10 Uhr [ - Direktlink - ] |
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung Also hab mal meine Suche auf hooks.h eingegrenzt und bei mir sind die Sachen in der GoldED-Installation überall (inkl. NDK3.9 und SDK4.0, mit Ausnahme des MOS-SDK (welches ich nicht nehme) wie folgt definiert: C++ code:struct Hook { struct MinNode h_MinNode; ULONG (*h_Entry)(); /* assembler entry point */ ULONG (*h_SubEntry)(); /* often HLL entry point */ APTR h_Data; /* owner specific */ }; /* Useful definition for casting function pointers: * hook.h_SubEntry = (HOOKFUNC)AFunction */ typedef unsigned long (*HOOKFUNC)(); Der einzige Unterschied bei MOS ist, dass VOID angegeben ist, statt leerer Funktionsparameter! Die Option -H (Danke gni!) zeigt mir, dass die includes aus .../gg/... genommen werden (die Anzahl der führenden Punkte variiert). Wenn meine Assigns zu diesem Zeitpunkt nicht lügen, zeigt gg: zu dem Verzeichnis der GCC3.3-Installation mitsamt der Header für das OS3.x. Ich hätte aber noch 2 weitere Fragen: Unter 2.95.3 konnte ich mühelos die strlen-Funktion aus C auf ein char* anwenden (ohne was zu includieren). Der 3.3 kennt das nicht. Muss ich hier irgend nen Standard-C-Header inkludieren, oder kann ich die Funktion gar nicht mehr verwenden und muss das Ganze über C++-Strings handhaben? Das nächste wäre die Behandlung von Default-Argumenten in Methoden: In meinen Büchern und im Web hab ich nix gefunden (oder aber ich habs immer übersehen?), das besagt, dass die Default-Argumente nur bei der Deklaration angegeben werden dürfen, nicht aber bei der Definition (hoffe, ich bring hier nicht wieder was durcheinander, will sagen, in den Header-Files der C++-Klassen kann ich Default-Argumente angeben, in den implementierenden Files bekomm ich vom 3.3er auf die Finger, wenn ichs dort genauso mache! Find ich an sich schade, da sich so die Methodensignaturen unterscheiden - für das Auge des Betrachters!)!? Woran liegt das denn - will sagen, an welcher Klausel des Standards? Ciao |
|||||
Reth
Nutzer
12.05.2007, 15:41 Uhr [ - Direktlink - ] |
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung Hallo nochmals und vielen Dank für eure Beteiligung! Zitat: Werde vllt. mal Dietmar Eilert fragen, wo ich genau nachsehen kann, welche Includes der Compiler hier anzieht. Oder kann ich mir das via make-Parameter irgendwie ausgeben lassen? Schaue bei Gelegenheit auch nochmal in alle installierten OS-Includes (3.x und 4), bzw. lass mir mal alles suchen, wo HOOKFUNC drin vorkommt und berichte dann (kann aber ne Weile dauern)! Ciao |
|||||
Reth
Nutzer
10.05.2007, 21:03 Uhr [ - Direktlink - ] |
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung Zitat: Hm, aber auch ein: C++ code:bzw.this->filterHook.h_Entry = (ULONG)HookEntry; this->filterHook.h_SubEntry = (ULONG)SMFilterFunc; C++ code:this->filterHook.h_Entry = reinterpret_cast<ULONG>(HookEntry); this->filterHook.h_SubEntry = reinterpret_cast<ULONG>(SMFilterFunc); Brachte nen Fehler: code:ScreenModeHookC.cc:16: error: invalid conversion from 'ULONG' to 'ULONG (*)()' ScreenModeHookC.cc:17: error: invalid conversion from 'ULONG' to 'ULONG (*)()' Hm, vielleicht muss ich genauer casten. also: C++ code:this->filterHook.h_Entry = reinterpret_cast<ULONG (*)()>(HookEntry); this->filterHook.h_SubEntry = reinterpret_cast<ULONG (*)()>(SMFilterFunc); Und siehe dann, nun klappts! Wieso hat das ganze dann aber zuvor der g++ des 2.95.3 anstandslos compiliert und das Programm wurde auch immer normal ausgeführt!? Ciao |
|||||
Reth
Nutzer
09.05.2007, 22:13 Uhr [ - Direktlink - ] |
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung Hallo nochmals, nun habe ich ein neues Problem: Nach den ersten Compileversuchen wurde das nicht angemeckert, aber nun bekomme ich bei folgenden Zeilen: C++ code:Den Fehler:// filterHook ist vom Typ struct Hook this->filterHook.h_Entry=reinterpret_cast<HOOKFUNC>(HookEntry); this->filterHook.h_SubEntry=reinterpret_cast<HOOKFUNC>(SMFilterFunc); code:ScreenModeHookC.cc:16: error: invalid conversion from 'long unsigned int (*)(...)' to 'ULONG (*)()' Wieso wird der Fehler erst jetzt gemeldet und nicht schon bei den ersten 3.3er Compilierversuchen? Das einzige, was ich getauscht habe war make, indem ich es in der GCC-GoldED-Installation durch das aktuellste AOS4-Binary getauscht habe!? Ciao [ Dieser Beitrag wurde von Reth am 2007-05-09 um 22:21 Uhr geändert. ] [ Dieser Beitrag wurde von Reth am 2007-05-09 um 22:21 Uhr geändert. ] |
|||||
Reth
Nutzer
09.05.2007, 09:20 Uhr [ - Direktlink - ] |
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung Zitat: Danke für den Tip! Zitat:Zitat:Sieht nicht so aus. Du kannst ja mal die Verzeichnisse mit diff vergleichen. Meinst Du die des 2.95.3 mit denen des 3.3 oder innerhalb einer Compilerversion? Ciao |
|||||
Reth
Nutzer
08.05.2007, 22:05 Uhr [ - Direktlink - ] |
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung Zitat: Hm, werds erstmal wegsichern oder umbenennen, nicht, dass der Compiler danach nicht mehr mag! So sieht übrigens der jew. Include-Verzeichnisbaum aus: 2.95.3: code:libraries (dir) clib (dir) sys (dir) rpc (dir) protocols (dir) nfs (dir) netinet (dir) net (dir) machine (dir) m68k (dir) arpa (dir) amitcp (dir) g++-3 (dir) proto (dir) inline (dir) a.out.h ansidecl.h ar.h assert.h bfd.h bfdlink.h bitstring.h bstring.h ctype.h db.h dirent.h err.h errno.h fcntl.h FlexLexer.h float.h fnmatch.h fts.h glob.h glue.h gnu.a.out.h grp.h gvarargs.h inetd.h init.h ix.h kvm.h limits.h locale.h malloc.h math-68881.h math.h memory.h mpool.h ndbm.h ndir.h netdb.h netgroup.h nlist.h packets.h param.h paths.h pwd.h ranlib.h regex.h regexp.h resolv.h search.h setjmp.h sgtty.h signal.h stab.def stab.h stdarg.h stddef.h stdio.h stdlib.h string.h strings.h struct.h sysexits.h syslog.h termcap.h termios.h time.h ttyent.h tzfile.h unistd.h user.h utime.h utmp.h values.h varargs.h vis.h wait.h 3.3 code:c++ (dir) libraries (dir) clib (dir) sys (dir) rpc (dir) protocols (dir) nfs (dir) netinet (dir) net (dir) machine (dir) m68k (dir) arpa (dir) amitcp (dir) g++-3 (dir) proto (dir) inline (dir) a.out.h ansidecl.h ar.h assert.h bfd.h bfdlink.h bitstring.h bstring.h ctype.h db.h dirent.h err.h errno.h fcntl.h FlexLexer.h float.h fnmatch.h fts.h glob.h glue.h gnu.a.out.h grp.h gvarargs.h inetd.h init.h ix.h kvm.h limits.h locale.h malloc.h math-68881.h math.h memory.h mpool.h ndbm.h ndir.h netdb.h netgroup.h nlist.h packets.h param.h paths.h pwd.h ranlib.h regex.h regexp.h resolv.h search.h setjmp.h sgtty.h signal.h stab.def stab.h stdarg.h stddef.h stdio.h stdlib.h string.h strings.h struct.h sysexits.h syslog.h termcap.h termios.h time.h ttyent.h tzfile.h unistd.h user.h utime.h utmp.h values.h varargs.h vis.h wait.h Gibts da noch mehr falsch Abgelegtes? Ciao |
|||||
Reth
Nutzer
08.05.2007, 10:28 Uhr [ - Direktlink - ] |
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung Zitat: Das liegt daran, dass diese Verzeichnisse in den jeweiligen include-Verzeichnissen liegen (wenn gewünscht kann ich davon auch ein Listing machen). Zitat:Zitat:Das weis ich nicht, vermutlich aber eher nicht. Nimm "list" und gut. Dann muss ich mich nochmal mit den STL-Komponenten befassen, welche Sortiertechniken/-möglichkeiten mir dort gegeben sind, da hier die Sortierung eine wichtige Rolle spielt. In Java kann man dass ja z.B. gut mit den Comparatoren bzw. Comparable machen. Hab kurz gekuckt! Und: Oh weh! Mir schwant Übles! Muss den <-Operator überladen, damit ich sort() anwenden kann! Ciao [ Dieser Beitrag wurde von Reth am 08.05.2007 um 10:43 Uhr geändert. ] |
|||||
Reth
Nutzer
07.05.2007, 22:57 Uhr [ - Direktlink - ] |
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung Hi nochmal, Zitat: Also: GoldED kommt u.a. mit 2 GCC-Installationen, die sich umschalten lassen. Dazu werden die entsprechenden Assigns angepasst und in die entsprechenden Verzeichnisse gewechselt (Path und was weiss ich noch alles). Die Verzeichnisstruktur sieht wie folgt aus: 2.95.3 (dir) code:Assigns:sbin (dir) m68k-amigaos (dir) var (dir) usr (dir) tmp (dir) sys (dir) share (dir) ps (dir) os-include (dir) man (dir) libexec (dir) lib (dir) info (dir) include (dir) html (dir) guide (dir) etc (dir) dvi (dir) bin (dir) AUTHORS COPYING COPYING.LIB INSTALL MIRRORS NEWS README VERSION code:bin Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/2.95.3/bin Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/bin C Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/2.95.3/bin Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/bin DEVS Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/2.95.3/sys/devs Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/sys/devs etc Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/2.95.3/etc Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/etc gg Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/2.95.3 Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user info Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/2.95.3/info Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/info L Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/2.95.3/sys/l Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/sys/l LIBS Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/2.95.3/sys/libs Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/sys/libs man Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/2.95.3/man Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/man S Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/2.95.3/sys/s Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/sys/s usr Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/2.95.3 Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user var Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/2.95.3/var Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/var 3.3 (dir) code:Assigns:sbin (dir) m68k-amigaos (dir) var (dir) usr (dir) tmp (dir) share (dir) ps (dir) os-include (dir) man (dir) libexec (dir) lib (dir) info (dir) include (dir) html (dir) guide (dir) etc (dir) dvi (dir) sys (dir) bin (dir) AUTHORS COPYING COPYING.LIB INSTALL MIRRORS NEWS NOTES-3.3 README VERSION code:bin Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/3.3/bin Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/bin C Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/3.3/bin Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/bin DEVS Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/3.3/sys/devs Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/sys/devs etc Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/3.3/etc Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/etc gg Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/3.3 Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user info Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/3.3/info Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/info L Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/3.3/sys/l Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/sys/l LIBS Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/3.3/sys/libs Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/sys/libs man Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/3.3/man Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/man S Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/3.3/sys/s Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/sys/s usr Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/3.3 Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user var Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/3.3/var Stuff:AOS4/Anwendungen/Prog/devkits/compilers/gcc/classic/user/var Je nachdem welchen Compiler Du in GoldED auswählst, wird der entsprechende Verzeichnisbaum aktiviert (s. Assign-Auszüge) und nur dieser verwendet! Ich frage mich allerdings, wieso im 3.3 im Vgl. zum 2.95.3 (meiner Meingun nach) sinnvolle Erweiterungen wie slist gecancelt wurden und sich anscheinend wohl "nur" auf den Standard konzentriert wurde. Kann ich denn die slist mit den vorhandenen Includes innerhalb des 3.3 dennoch nutzen? Oder wie ist denn die Standard-Alternative zur slist? Ciao |
|||||
Reth
Nutzer
05.05.2007, 21:21 Uhr [ - Direktlink - ] |
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung Zitat: Hm, schade. Gibt es einen adäquaten Ersatz in der STL? Zitat: Nun nicht ganz, da beide Compiler bei GoldED einen komplett eigenen Verzeichnisbaum haben. In dem des 2.95.3 liegen u.a. die g++-3 und in dem des 3.3er die g++-3 und c++! Ciao |
|||||
Reth
Nutzer
04.05.2007, 22:14 Uhr [ - Direktlink - ] |
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung Jep! Vielen Dank! An diesem Problem war der Namespace schuld! Werde nochmal meinen C++ Primer dazu wälzen, aber gibt es irgendwo eine Übersicht über den momentanen C++ Standard, so dass man klar nachlesen kann, was man wie tun sollte? Meine Suche nach dem C++-Standard im Web gab diesbezüglich noch kein positives Ergebnis! Ein anderes Problem habe ich aber noch! Der GCC 3.3 findet die slist nicht, der 2.95.3 allerdings schon! Bin immer noch bei den GCCs von GoldED AIX! Nun ist es so, dass die includes dazu beim 2.95.3 im Unterverzeichnis g++-3. Dieses gibt es auch beim 3.3er, dort ist aber auch noch das Unterverzeichnis c++, welches die anderen STL-Typen enthält (zumindest die, welche ich nehme), dafür keine slist! Wenn ich nun das g++-3 Verzeichnis beim GCC 3.3 bei den Compiler Options mit als Include angebe, dann bekomme ich massig deprecated Meldungden und Fehler angezeigt! Weiss jemand, wie hier zu verfahren ist, damit die richtigen Includes genommen werden? Oder sind im neueren C++ Standard nicht mehr alle Container der STL (von GDI glaub?) enthalten? Ciao René [ Dieser Beitrag wurde von Reth am 04.05.2007 um 23:09 Uhr geändert. ] |
|||||
Reth
Nutzer
03.05.2007, 21:24 Uhr [ - Direktlink - ] |
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung @mausle: Danke! Werd ich tun! Mit Namespaces war/bin ich noch nicht so firm, da das bisher beim 2.95.3 wohl kein Problem war! hatte folgendes: C++ code:#include <string> ... void setTitle(const string title = "") { displayTitle = title; } Gab keine Probleme beim comilieren! Ciao |
|||||
Reth
Nutzer
02.05.2007, 20:28 Uhr [ - Direktlink - ] |
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung Zitat: Z.B.: Auszug aus ner Header Datei (keine .cpp Datei dazu, alles im Header aber nicht als inlines) : C++ code:void setTitle(const string title = "") { displayTitle = title; } Parse error before '=' token Meines Wissens sind Default-Argumente doch legal!? Oder hier: C++ code:string getTitle() const { return displayTitle; } Parse error before ')' token Wobei eine Zeile obendrüber folgendes steht (ohne Error): C++ code:BOOL isExclusive() const {return exclusive; } ? Da werd einer schlau draus! Sicher gibt es auch ne Menge Folgefehler, aber das sind die ersten beiden! @thomas: Ich verwende nicht die Version des AOS4-SDK, sondern die von GoldED! Da ist die 2.95.3 (oder .4?) dabei und die 3.3. Ich will zunächst mal 68k-Sourcen erzeugen, die 3.1-kompatibel sind, um eine größtmögliche "Userbasis" zu haben! Ciao |
|||||
Reth
Nutzer
01.05.2007, 21:40 Uhr [ - Direktlink - ] |
Thema: C++ von GCC 2.95.3 nach GCC 3.3 portieren
Brett: Programmierung Hallo zusammen, auf meiner Suche im Web zu diesem Thema bin ich noch nicht so recht fündig geworden. Da ich GoldED AIX zur Entwicklung verwende habe ich beim C++ und dem GCC die Wahl zw. diesen beiden Compilern. Bisher habe ich mit dem 2.95.3 gearbeitet und mein Projekt compilierte mit diesem Compiler fehlerlos. Da 2.95.3 unter AOS4 bei mir aber nicht funktioniert, der 3.3er scheinbar schon, will ich nun meine Sourcen mit dem GCC 3.3 compilieren. Doch ich bekomme nun eine endlose Latte von Fehlermeldungen, die ich beim 2.95.3 nicht hatte! Gibt es irgendwo sachdienliche Hinweise, die einem hier bei der Portierung von C++ vom 2.95.3 auf den 3.3 helfen?! Vielen Dank schon einmal Ciao |
|||||
Reth
Nutzer
29.04.2007, 21:52 Uhr [ - Direktlink - ] |
Thema: GoldED AIX und Stack für gcc/g++?
Brett: Amiga, AmigaOS 4 Hallo zusammen, wie kann ich denn unter GoldED den Stack für den gcc bzw. g++ erhöhen? Wenn ich in den Compilereinstellungen einen Stack für make eintrage (verwende ja makefiles und das Make-Menü von AIX und GCC), dann bekommt der Compiler unter AOS4 dennoch nur 32kB Stack!? Dann bekomm ich nen GR (wobei nicht sicher ist, ob der kleine Stack die Ursache ist, aber das will ich ja herausfinden). Das Ganze passiert nur mit dem 2.95.3 GCC, der 3.3er geht! Vielen Dank schon mal Ciao |
|||||
Reth
Nutzer
20.04.2007, 20:52 Uhr [ - Direktlink - ] |
Thema: Connexion Wackelkontakt
Brett: Amiga, AmigaOS 4 So nachdem die Karte aus heiterem Himmel wieder ausgefallen ist (hab weder sie noch den Rechner berührt), hab ich sie nun mal in nen anderen Slot gesteckt und warte auf den nächsten Ausfall! Ciao |
|||||
Reth
Nutzer
20.04.2007, 17:28 Uhr [ - Direktlink - ] |
Thema: Connexion Wackelkontakt
Brett: Amiga, AmigaOS 4 So hab mal alles gereinigt und PINs gebogen, muss nun abwarten, ob die Karte mal wieder ausfällt! Ciao |
|||||
Reth
Nutzer
20.04.2007, 12:50 Uhr [ - Direktlink - ] |
Thema: Connexion Wackelkontakt
Brett: Amiga, AmigaOS 4 Zitat: Vergoldete Kontakte, auch mehrfache Reinigung half nix! @All: Hab auch schon mal die PINs aufgebogen, half auch nicht (werd ich nochmal machen), weiterhin hab ich schon mal einige Stellen nachgelötet - umsonst. Tippe entweder auf einen Haarriss oder doch noch ne kalte Lötstelle. Werde das mit den PINs nochmal probieren wie gesagt und mich dann nochmal melden! Ciao [ Dieser Beitrag wurde von Reth am 20.04.2007 um 12:51 Uhr geändert. ] |
|||||
Reth
Nutzer
20.04.2007, 00:47 Uhr [ - Direktlink - ] |
Thema: Connexion Wackelkontakt
Brett: Amiga, AmigaOS 4 Hallo allerseits, vielleicht kennt jmd. das Problem: Habe eine Connexion, die eigentlich schön schnell in meinem A400 arbeitet. Allerdings nicht sehr zuverlässig. Ich weiss, dass der BNC-Port unzuverlässig ist, den nutze ich aber nicht, sondern den AUI-Port über eine MAU auf RJ45. Nun ist es so, dass die Karte manchmal aus heiterem Himmel nicht erkannt wird, wenn ich dann allerdings etwas auf den gesteckten Chips oder der Karte selbst herumdrücke geht es meistens. Allerdings nicht immer! Kennt jmd. zufällig das Problem und hat eine Lösung dafür? Vielen Dank schon einmal Ciao |
|||||
Reth
Nutzer
19.04.2007, 23:02 Uhr [ - Direktlink - ] |
Thema: S: Cubic IDE
Brett: Kleinanzeigen (keine Auktionen!) Hallo zusammen, falls das jmd. zu nem guten Preis zu verkaufen hat, bin ich für Vorschläge offen! Ciao |
|||||
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |