Zitat:

---

akl:
Vermutlich kommt der C++ Compiler mit den Macros für variable Argumente nicht klar, d.h. in dem Fall varargs68k

---

Zitat:

---

thomas:
*>

---

Zitat:

---

[ujb]:
#include "cubic:ide/devkits/sdk/morphos/1.0/os-include/libraries/mui.h"

---

Zitat:

---

#include "cubic:ide/devkits/sdk/morphos/1.0/os-include/proto/muimaster.h"

---

Zitat:

---

>cubic:ide/devkits/sdk/morphos/1.0/os-include/inline/muimaster.h:7: ppcinline/macros.h: No such file or directory
>MuiCalc.cpp:119: macro 'LP1NR' used with too many (13) args

---

Zitat:

---

mui.h und muimaster werden zwar nun gefunden, aber gcc beschwerte sich über einen nicht vorhandenen inline Ordner.
Den habe ich mal einfach erzeugt und (um es irgendwie zu testen) den inhalt von ppcinline dahin kopiert, aber danach kommt es zu obigem Fehler.

---

Zitat:

---

Irgendwie beschleicht mich das Gefühl, dass da irgendwas mit den Pfaden generell nicht stimmt.

---

Gut erkannt

Zitat:

---

Es handelt sich um eine (fast) jungfräuliche Cubic Installation. Muss man die überhaupt anpassen?

---

Zitat:

---

Bei solchen Dingen bin ich völliger Amateur (deshalb mag ich auch Visual Studio ;-) )

---

Zitat:

---

Der_Wanderer:
Ich habe nirgends mehr stdio.h eingebunden, und alle fopen, fprintf, fclose etc. gemapped.
Trotzdem bekomme ich hier noch einige Funktionen, aber der Linker sagt mir nicht, in welcher Datei ich genau darauf referenziere.

---

Zitat:

---

11.Work:Sourcecodes/c_dumb> gcc -noixemul -nostartfiles -o dumb.library #?.o -lm -lamiga
/gg/lib/libnix/libnix.a(__stdio.o)(.text+0x40): undefined reference to 'exit'
/gg/lib/libnix/libnix.a(open.o)(.text+0x26c): undefined reference to '_WBenchMsg'
/gg/lib/libnix/libnix.a(open.o)(.text+0x234): undefined reference to 'exit'
/gg/lib/libnix/libnix.a(raise.o)(.text+0x82): undefined reference to 'exit'
collect2: ld returned 1 exit status

---

Zitat:

---

Micha1701:
Mir war auch schon aufgefallen, daß die mpega_lib gelegentlich etwas penibler mit mp3s ist. Wo Windows-Player anstandslos abspielen schmiert die gelegentlich ab...

---

Zitat:

---

whose:
Kannst Du das evtl. mal näher erläutern? Also, wie die Automatismen funktionieren und aus welchen Gründen die in Amiga shared-Libraries nicht greifen?

---

Zitat:

---

Wenn ich da mal offen sprechen darf, genau diese Informationen sind nur sehr schwer (wenn überhaupt) zu finden, wenn man sich die einschlägigen Dokumentationen ansieht...

---

Im allgemeinen nennt man solche Initialisierungen Konstruktoren und Destruktoren

Zitat:

---

whose:
Da kann man doch mal erwähnen, daß er die meisten dieser Referenzen per -lauto "erschlagen" kann, wenn er die Libbases nicht von Hand deklarieren und initialisieren will?

---

Zitat:

---

Das ich auf die Gefahr dieser Lösung bei Amiga-Shared-Libs nicht eingegangen bin, war aber mein Versäumnis. Verzeihung.

---

Zitat:

---

Der_Wanderer:
Also diese lib ist extra als lib konzipiert, nicht als Amiga Shared lib, aber sie benutzt keine systemabhängigen Sachen, und der Code sollte re-entrant sein.

---

Zitat:

---

Wie linkt ihr ein Program, das fopen, malloc etc. nutzt ?

---

Zitat:

---

whose:
Hmm auch fopen() [in vc.lib]?

---

Vorallem das

Zitat:

---

Ich frage so dumm, weil ich mich wirklich nur dunkel erinnere... ich hatte die zlib vor ein paar Wochen "mal eben" für den vbcc präpariert und mußte mir dann noch die posixlib besorgen, weil ich eben nicht fertig linken konnte. Und ich meine, das Problem wäre fopen & Co. gewesen. Kann aber auch gut sein, daß ich das falsch in Erinnerung habe. Ich habe mit diesen Funktionen eher selten zu tun.

---

Zitat:

---

Der_Wanderer:
Dann darf ich aber vermutlich auch nicht mit -noixemul compilieren, oder?

---

Zitat:

---

-lnix wird nicht gefunden. Im Order GG:lib/libnix/ gibt es die aber. Evtl. muss ich noch den Pfad dazu etzen?

---

Zitat:

---

whose:

Zitat:

---

Der_Wanderer:
Hautsächlich Dinge wie malloc, free, fopen etc.

---

Hmm *kopfkratz* wenn ich mich recht entsinne, gehören diese Funktionen zu denen, die beim vbcc in der posixlib vorhanden sind.

---

Zitat:

---

Da Du ohne ixemul kompilieren willst, würde ich es an Deiner Stelle mit der libnix probieren, also laut gni dann vermutlich -lnix beim Linken.

---

Zitat:

---

Der_Wanderer:
BTW, die dumb lib ist eine Bibliothek zum Umwandeln von MOD in Audio.
Es werden sehr viele Formate unterstützt und die Qualität soll sehr gut sein. Ich wollte daraus eine .library machen, damit man das überall benutzen kann.

---

Zitat:

---

Der_Wanderer:
objdumb sage aber, dass es 68K wäre.

---

objdump

Zitat:

---

ld libdumb.a dumb_funcs.o dumblib_init.o -noixemul -nostartfiles -lamiga

---

Zitat:

---

Der_Wanderer:
Wenn ich -llibdumb mache, bekomme ich einen Fehler: Datei nicht gefunden.

---

Zitat:

---

Die Datei libdumb.a habe ich ins Hauptverzeichnis/aktuelle Verzeichnis kopiert.

---

Zitat:

---

Wo soll die Datei hin?

---

Zitat:

---

Oder wie sage ich GCC, wo er die Datei finden kann ?

---

Zitat:

---

Meine Frage war auch, ob ich überhaupt richtig denke, dass eine ".a" Datei eine vorkompiliertes Binary ist dass man dazu linken kann.

---

Zitat:

---

Sorry, hab noch nicht viel mit GCC gemacht. Ich programmiere sonst nur unter VisualC++, dort ist alles ein wenig einfacher.

---

Zitat:

---

DariusBrewka:
Die datei heißt libdump.a, dann heißt der Linkerdirektive -dump nicht -llibdump, das lib davor und das .a dahinter fügt der linker selber hinzu.

---

Zitat:

---

R-TEAM:
Bei P96 kann ich das zwar auch einstellen nach setzen der option und den screen sogar testen .. aber er ist im screenmodeReq nicht anwählbar..

---

Zitat:

---

platon42:
Fahre den jetzt mit 1280x1024x16 Bit @ 50Hz, mit einer Pixelclock von 90MHz und einer MemClock von 50MHz. Blitterfehler sind da schon sehr selten.

---

Zitat:

---

Für die CV64 gehen solche Auflösungen nur mit CGX4, Picasso96 lässt diese Pixelclocks gar nicht erst zu...?

---

Zitat:

---

CarstenS:
@platon42:
> Trotzdem hat sich das Investment gelohnt, denn der hat gute 8-9 Jahre gehalten
Länger nicht?! Dann hätte mein Eizo ja ca. 2000 den Geist aufgeben müssen. Ne, das geht nun wirklich nicht...

---

Zitat:

---

Der_Wanderer:
Ein TFT läuft normalerweise auf 60-max. 70Hz. Über 75Hz geht natürlich nicht und macht Probleme.

---

Zitat:

---

Bei analog Kabeln kommen niedrigere Hz Zahlen besser rüber, weil weniger Daten durch das dünne Kabel müssen. Hier gilt, je weniger Hz desto sauberer das Bild.

---

Zitat:

---

Stelle also auf 60Hz ein, und du hast das beste Bild. Ein TFT flimmert ja nicht im Gegensatz zu einen CRT, deshalb sind 60Hz völlig ausreichend.

---

Zitat:

---

technox309:
grundsätzlich kannst du ja bei der Installation ein Logfile mitschreiben lassen. Anhand deises Logfiles siehst du ja welche Datein wo hin kopiert wurden. So kann man gründlichst Software wieder vom System entfernen.

---

Zitat:

---

whose:
Hmm, leider nein. Auf die gleiche Weise habe ich es probiert und einfach mal GWDRAGBAR gegen GWDEPTH ausgetauscht, die Größe und Position angepaßt und das Depth-Gadget reagiert nicht.

---

Zitat:

---

aPEX:
Kann das Thema wohl als erledigt betrachten, wird sich wohl auch niemand finden der den Source fixen kann. Typisch Amiga.

---

Zitat:

---

whose:
Bei den früheren Versionen von vbcc war es ja so, daß man die .lib einfach per join zusammenfügte. Diese Information habe ich allerdings auch erst nach reichlich Suchen bekommen damals.

---

Zitat:

---

Heute habe ich entdeckt, daß dem aktuellen Amiga-VBCC ein eigener ar beiliegt.

---

Zitat:

---

Nun meine Frage: Stellt man die Linklibs weiterhin einfach mit join zusammen oder sollte man dazu den beigefügten ar benutzen?

---

Zitat:

---

Ich frage, weil dieser ar z.B. bei der t-Option mosert, daß er das Format der .lib-Datei nicht erkennt?

---

Zitat:

---

MaikG:
wo ist die SysBase?

---

Zitat:

---

Holger:
Wenn jemand meint, mit Uralt-compilern etc. die besten Ergebnisse erzielen zu können, soll er damit glücklich werden.

---

Zitat:

---

Holger:
Meine Frage zielte darauf ab, ob es ein [Caching-]Tool gibt, das man jemanden, der es nicht hat, empfehlen könnte.

---

Zitat:

---

Und der gcc ist nunmal so, wie er ist. Wesentliche Änderungen, die von den main-Entwicklern nicht übernommen werden würden, bringen nur mehr Aufwand als Nutzen.

---

Das ist seit langem bekannt

Zitat:

---

Das hat man bei StormC4/WarpOS gesehen.

---

Zitat:

---

Holger:
gibt es (k)ein freies Tool, das so wie anno dazumal DynamiCache funktioniert?

---

Zitat:

---

Das würde gcc wahrscheinlich drastisch beschleunigen, was ich aber nicht weiß, weil ich damals noch keinen gcc verwendet habe.

---

Zitat:

---

platon42:
Und warum man sich mit SAS/C statt GCC herumschlägt ist recht einfach: GCC erzeugt nicht immer besseren Code

---

Das glauben Dir die hier versammelten GCC Experten doch eh nicht

Zitat:

---

und SAS/C ist auf einem 68060@50MHz schneller beim Kompilieren von Poseidon mit vollen Optimierungen als auf einem 1 GHz PPC mit GCC.

---

Zitat:

---

precompiled Headers gibts beim GCC ja nicht

---

Zitat:

---

Solar:
Du meinst Caching

---

Zitat:

---

precompiled Headers?

---

Zitat:

---

Reth:
Das bedeutet ja dann wohl, dass ich nirgends im Projekt ein

C code:

---

struct IntuitionBase *IntuitionBase;

---

mehr brauche, sondern nur meine Libraryfunktionen benutze und deren Header (prototypes) inkludiere!?

---