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 3 4 5 6 7 -8- 9 10 11 12 13 >> Letzte Ergebnisse der Suche: 1106 Treffer (30 pro Seite)
gni   Nutzer

19.05.2006, 15:28 Uhr

[ - Direktlink - ]
Thema: Datatypes und 24Bit
Brett: Programmierung

Zitat:
bubblebobble:
Möglicherweise brauchen auch manche Datatypes CGX, wenn du mit 24bit Bildern hantierst.

CGX hat mit 24-Bit für PicDTs nichts zu tun. Mit CGX kommt ein PicDT gar nicht in Berührung. Ein PicDT verwendet das V43 API wenn echtes 24Bit benutzt werden soll und um den Rest hat sich die Superklasse zu kümmern ;-)
 
gni   Nutzer

04.05.2006, 15:25 Uhr

[ - Direktlink - ]
Thema: undefined reference to cos
Brett: Programmierung

Zitat:
Flipflop:
Folgendes wird verwendet...

Du solltest den _Linkaufruf_ posten wie er in der Shell angzeigt wird, nicht nur Optionen.
 
gni   Nutzer

03.05.2006, 16:14 Uhr

[ - Direktlink - ]
Thema: undefined reference to cos
Brett: Programmierung

Zitat:
Flipflop:
Jemand eine Idee? Verzweifle schon fast...

Garantiert eine FAQ... Poste die komplette Link-Kommandozeile.
 
gni   Nutzer

03.05.2006, 15:29 Uhr

[ - Direktlink - ]
Thema: Open Source Programme übersetzen
Brett: Programmierung

Zitat:
Holger:
Wenn configure in der Lage wäre, Dich einfach danach zu fragen, wäre es vollkommen unnötig, irgendetwas für die build-plattform zu übersetzen.

Übersetzen geht schon - das Ausführen ist das Problem, da Programme von $host nicht auf $build laufen. Cross-compiler erstellen nunmal Programme für "ihr" Target. Daraus kann man lernen, das Software, die während eines configure-Laufes Testprogramme laufen lassen will, nicht per "automatisch" configuriert werden kann.
 
gni   Nutzer

03.05.2006, 11:16 Uhr

[ - Direktlink - ]
Thema: Open Source Programme übersetzen
Brett: Programmierung

Zitat:
DariusBrewka:
Zitat:
Der Compiler des Buildsystems kann logischerweise nicht benutzt werden um etwas über die Zielplatform herauszufinden. Das sollte einleuchtend sein.
Es wird in speziellen Fällen wohl so, aber Festgeschrieben ist das nicht und schon garnicht einleuchtend.
Ich will garnicht wissen, wo Dein Verständnisproblem ist.
 
gni   Nutzer

03.05.2006, 10:00 Uhr

[ - Direktlink - ]
Thema: Open Source Programme übersetzen
Brett: Programmierung

Zitat:
Holger:
long ist beim Amiga 4 bytes?

Ich kenne keinen Amiga C-Compiler, der das anders macht.
 
gni   Nutzer

03.05.2006, 09:58 Uhr

[ - Direktlink - ]
Thema: Open Source Programme übersetzen
Brett: Programmierung

Zitat:
DariusBrewka:
Ich weiß jetzt nicht wo das Problem sein soll, aber warum soll man unter Linux mit einem Linux Compiler nicht herausfinden könne, ob AROS nun Beispielweise einen Growing stack pointer hat oder nicht? oder wie die Datenfeldlänge bestimmter Datentypen unter AROS sind. Für mich allsamt keine Argumente die hinderlich daran sind.

Der Compiler des Buildsystems kann logischerweise nicht benutzt werden um etwas über die Zielplatform herauszufinden. Das sollte einleuchtend sein.
 
gni   Nutzer

03.05.2006, 09:54 Uhr

[ - Direktlink - ]
Thema: Open Source Programme übersetzen
Brett: Programmierung

Zitat:
DariusBrewka:
code:
checking for growing stack pointer... configure: error: cannot run test programm while cross compiling


Du hast einfach Pech. Das Programm, das Du zu übersetzen versuchst, ist nicht Cross-Compiler tauglich.
 
gni   Nutzer

29.04.2006, 10:38 Uhr

[ - Direktlink - ]
Thema: Umsetzung StormC 4 -> gcc
Brett: Programmierung

Zitat:
Uwe:
Ich habe 2.1 installiert gehabt.

Die basiert auf einer Beta-Version, die einige schwerwiegende Fehler hatte.
Zitat:
Version 1.2 ist immer bei den gcc-Paketen dabei.
Was neueres wurde auch nie offiziell rausgegeben.
Zitat:
>2.0 gibt's auf der libnix-Homepage (bei Sourceforge.net).
Das ist _nicht_ die Homepage von libnix. Es gibt keine.
 
gni   Nutzer

27.04.2006, 18:04 Uhr

[ - Direktlink - ]
Thema: Umsetzung StormC 4 -> gcc
Brett: Programmierung

Zitat:
Holger:
Zitat:
Man nehme bzero/memset
Müssen die nicht auch innerhalb von libnix implementiert werden?
bzero nicht, aber beide sind vorhanden.
Zitat:
Vielleicht sollte man, wenn man schon dabei ist, da auch mal einen kritischen Blick drauf werfen...
Mach mal...
Zitat:
Aber evtl. delegieren die auch nur an eine AOS-Funktion.
Welche sollte das sein?
 
gni   Nutzer

27.04.2006, 16:36 Uhr

[ - Direktlink - ]
Thema: Umsetzung StormC 4 -> gcc
Brett: Programmierung

Zitat:
Original von Holger:
Aber bei den meisten Prozessoren ist die Verwendung zweier Variablen, die beide in jedem Durchlauf verändert werden, aufwändiger als der Unterschied zwischen einem Test auf 0 und einem Vergleich. Somit ist folgendes besser:

for(b=a+l; a!=b; a++) *a=0;

Am besten ist was ganz anderes: Man nehme bzero/memset, dann hätte es den Bug auch nicht gegeben. Aber genau die Funktionen sollten da vermieden werden.
 
gni   Nutzer

27.04.2006, 09:10 Uhr

[ - Direktlink - ]
Thema: Umsetzung StormC 4 -> gcc
Brett: Programmierung

Zitat:
Dietmar:
Warum nicht:
code:
i = l;
while (i)
    a[--i] = 0;



Oder so?
code:
for(;l!=0;l-=sizeof(size_t))
 *a++ = 0;

 
gni   Nutzer

27.04.2006, 09:06 Uhr

[ - Direktlink - ]
Thema: x86 native Amiga Shared Libraries unter Amithlon
Brett: Programmierung

Zitat:
bubblebobble:
Vorweg: Vergiss alle -O<x> mit x > 2.
Zitat:
i686be-amithlon-gcc -noixemul -c -o fxlib_init.o fxlib_init.c
Wenn das Objekt nur .o bekommt brauchst Du -o nicht.
Zitat:
i686be-amithlon-gcc -noixemul -nostartfiles -r -o mylib.library fxlib_init.o mylib.o -lm utils_debug.o utils_string.o
Bibliotheken kommen immer *nach* allen Objekten. Sollte aber zumindest hier keine Rolle spielen, wenn mylib.o die Mathefunktionen benutzt.
Zitat:
i686be-amithlon-gcc
Gibt es sowas wie i686be-amithlon-nm und i686be-amithlon-objdump? Wie ist die Ausgabe von i686be-amithlon-nm bzw. von i686be-amithlon-objdump --syms? Gibt es da *UND* Symbole?
 
gni   Nutzer

26.04.2006, 15:09 Uhr

[ - Direktlink - ]
Thema: x86 native Amiga Shared Libraries unter Amithlon
Brett: Programmierung

Zitat:
bubblebobble:
Gemäß der Readme muss man die Amithlon Binaries mit "-r" linken, steht sogar dabei "... like in the good old powerup days." oder so ähnlich.

Das klang nach Deiner Beschreibung auch ganz nach -r.
Zitat:
Und was heisst das jetzt für mich ? Wie bekomme ich dann die mathematischen Funktionen zum laufen, oder evtl. noch andere Dinge die ich benutze ?
Wenn Du mit -lm linkst müßte es eigentlich funktionieren...
Zitat:
Was ist z.B. wenn ich OS Libraries benutze (z.B. graphics.library), wo ich per OpenLibrary() rankomme, das betrifft es aber nicht, oder ?
Wenn Amithlon so ähnlich arbeitet wie PowerUp, dann betrifft es Code, der dessen Interface benutzt, dh. "native" Code. Das eigentliche Problem ist dabei, das die Programme "Objektfiles" sind und sowas kann der GNU-Linker nur mit -r erzeugen. Dann bekommt man aber keine Warnungen, weil das eigentliche Linken aus Sicht des Linkers noch kommt.

Am besten Du linkst mal mit -v und -Wl,-t. Dann sollte der Linker dir sagen was er so macht. Danach kannst Du das Programm mit nm/objdump (den Amithlonversionen) untersuchen. Wenn es da Symbole gibt die, als *UND* gekennzeichnet sind, dann fehlt was.
Achja, am besten erstmal ohne "-s" linken und auch nicht strip benutzen.

[ Dieser Beitrag wurde von gni am 26.04.2006 um 17:23 Uhr geändert. ]
 
gni   Nutzer

26.04.2006, 13:25 Uhr

[ - Direktlink - ]
Thema: Umsetzung StormC 4 -> gcc
Brett: Programmierung

Zitat:
Holger:
Statt einer for-Schleife benutzt man eine do-while Schleife, warum? Weil man eine Vortest einsparen wollte (was dann bei Uwe für den Absturz gesorgt hat)?

Offensichtlich hat vorher niemand 0-Bytes mit calloc() angefordert. IMHO ist das der wirkliche Bug.
 
gni   Nutzer

26.04.2006, 13:22 Uhr

[ - Direktlink - ]
Thema: x86 native Amiga Shared Libraries unter Amithlon
Brett: Programmierung

Zitat:
bubblebobble:
run_elf beschwert sich über alle Funktionen, die dazu gelinkt wurden,
wie pow() sin() etc.

Dann sind sie definitiv _nicht_ dazugelinkt.

Dieses Problem gab es bei PowerUp ebenfalls, da dessen Programme (zwangsweise) Referenzen auf PowerUp-Kernelsymbole enthielt und diese Referenzen erst zu Laufzeit aufgelöst wurden. In Ermangelung einer besseren Alternative wurde mit -r gelinkt. Das hat aber den unangehmenen Nebeneffekt, das der Linker sich nicht mehr über nicht-auflösbare Referenzen beschwert. So hat man meist erst zur Laufzeit festgestellt, das was fehlt. Am besten Du analysierst Deine Libraries mit objdump oder nm.
 
gni   Nutzer

26.04.2006, 08:58 Uhr

[ - Direktlink - ]
Thema: Umsetzung StormC 4 -> gcc
Brett: Programmierung

Zitat:
Holger:
Wow, ja das ist C-Code der alte Schule.

Welche Stelle verstehst Du nicht?
Zitat:
Immer nach dem Motto "je krypischer es aussieht, desto höher muß wohl die Performance sein".
Woher nimmst Du diese Weisheit?
Zitat:
Tja, irgendwann fällt so ein Mist jemanden auf die Füße, und wie so oft, jemanden, der nix dafür kann.
Ein Glück wir haben "Experten" wie Dich :-/
 
gni   Nutzer

25.04.2006, 09:29 Uhr

[ - Direktlink - ]
Thema: Umsetzung StormC 4 -> gcc
Brett: Programmierung

Zitat:
Uwe:
StormC liefert bei malloc(0) einen gültigen Zeiger. gcc/ixemul stürzt bei einem malloc(0) ab, da laut ixemul-Sourcen direkt auf AllocMem(0, ...) abgebildet wird.

Gibt es wirklich einen Crash? Bei Allokationen <MINSIZE wird MINSIZE allokiert. Und nur Größen über einem bestimmten Limit werden direkt per AllocMem() bedient.
Zitat:
libnix funktioniert auch nicht (fehlende Funktionen, weitere Inkompatibilitäten)
Was fehlt? Welche weiteren Inkompatibilitäten? Zumindest liefert malloc(0) einen gültigen Zeiger, wenn ich die Quellen des libnix-malloc richtig lese. ixemul müßte laut Quellen auch einen gültigen Zeiger liefern. Davon abgesehen, Du willst garantiert für scummvm kein ixemul.
 
gni   Nutzer

21.04.2006, 15:15 Uhr

[ - Direktlink - ]
Thema: x86 native Amiga Shared Libraries unter Amithlon
Brett: Programmierung

Zitat:
Kaesebroetchen:
Ich weiss nicht inwiefern man das auf Amithlon übertragen kann, aber hier ist von einer stubs.h die rede die man angeblich braucht:

Diese Datei wird bei m68k von inline/macros.h benötigt.
Zitat:
http://www.zerohero.se/cross/os3.html
Die Informationen dort sind teilweise mit Vorsicht zu geniessen :-/ Der Abschnitt zu macros.h ist komplett falsch...
 
gni   Nutzer

21.04.2006, 12:53 Uhr

[ - Direktlink - ]
Thema: PDA-Palm
Brett: Amiga, AmigaOS 4

Zitat:
o.eschi:
Aber wo zum Geier liegt überhaupt das usbpalm.device???

Im Speicher ;-)
Zitat:
Habe ich gerade einen Denkfehler???
Ja. Lies die Poseidon-Dokumentation.
 
gni   Nutzer

21.04.2006, 12:51 Uhr

[ - Direktlink - ]
Thema: 68060er und dann?
Brett: Amiga, AmigaOS 4

@analogkid:
Nur wenn es sich um "schneller" handelt.
 
gni   Nutzer

21.04.2006, 11:15 Uhr

[ - Direktlink - ]
Thema: x86 native Amiga Shared Libraries unter Amithlon
Brett: Programmierung

Zitat:
Kaesebroetchen:
C:\CrossCompiler\AmiDevCpp\usr\local\amiga\lib\gcc-lib\m68k-amigaos\2.95.3

Der Compiler ist für m68k-amigaos und deshalb:
Zitat:
Unter anderem eben dieses -lamigastubs das ich hier allerdings entfernt habe.
hat "-lamigastubs" da nichts zu suchen. Diese Bibliothek gibt es für m68k-amigaos nicht und hat es auch nie gegeben.

Was sagt gcc -dumpspecs? Ist diese Bibliothek da auch enthalten?
 
gni   Nutzer

21.04.2006, 11:11 Uhr

[ - Direktlink - ]
Thema: x86 native Amiga Shared Libraries unter Amithlon
Brett: Programmierung

Zitat:
bubblebobble:
Was ist denn die SPECS Datei, und wo kann ich sie finden ?
(sorry, wenn das eine blöde Frage sein sollte)

Ich hatte doch geschrieben, wie Du die finden kannst: gcc -v sagt Dir wo sie ist.

Mit dieser Datei kann den GCC "konfigurieren". Das sollte man aber nur tun wenn man *wirklich* weis, was man tut.
 
gni   Nutzer

21.04.2006, 09:04 Uhr

[ - Direktlink - ]
Thema: 68060er und dann?
Brett: Amiga, AmigaOS 4

Zitat:
Cego:
Läuft die wb mit hsmathlibs auch spürbar schneller?

Wenn Du fest daran glaubst, ganz sicher... :-(
 
gni   Nutzer

21.04.2006, 08:57 Uhr

[ - Direktlink - ]
Thema: x86 native Amiga Shared Libraries unter Amithlon
Brett: Programmierung

Zitat:
bubblebobble:
/gg/i686be-amithlon/bin/ld: cannot open -lamigastubs: No such file or directory

Da scheint dann was zu fehlen oder die Bibliothek heisst jetzt anders. Versuch mal beim Linken mit -nostdlib zu arbeiten und alle benötigten Bibliotheken mit -l<name> selber anzugeben (wie die heissen, mußt Du selbst rausfinden). Oder Du erzeugst eine dummy libamigastubs.a, die Du dann entweder global installierst oder bei Deinem Projekt (dann mußt Du beim Linken -L. angeben). Oder Du editierst die specs Datei (wo die liegt sagt Dir "gcc -v")
 
gni   Nutzer

19.04.2006, 09:10 Uhr

[ - Direktlink - ]
Thema: x86 native Amiga Shared Libraries unter Amithlon
Brett: Programmierung

Zitat:
bubblebobble:
Ja, die AHI Sourcen habe ich durchgesehen, kann aber die entsprechende Stelle nicht finden.

Bei AHI werden die Interface-Stubs für jedes Target per sfdc gebaut. Dieses Programm (ein Perl-Skript) weiss, was für jedes mögliche Target zu tun ist. Was Du suchst ist in Device/Makefile.in zu finden (gatestubs.h, gatestubs.c). Für Amithlon könnte der Aufruf so aussehen:
code:
sfdc --target=i686be-amithlon --mode=gatestubs --output gatestubs.c --gateprefix=gw --libprefix=_ --libarg=last --addvectors=device ../../ahisrc-6.0/Include/SFD/ahi_lib.sfd

Obs korrekt ist und/oder funktioniert, das kann ich nicht sagen.
 
gni   Nutzer

13.04.2006, 10:43 Uhr

[ - Direktlink - ]
Thema: PicassoIV kein Bild über Flickerfixer mit Z4 Board + Videoslot-Adapter
Brett: Amiga, AmigaOS 4

Zitat:
Pro2-2001:
Das Early-Startup-Menu sollte doch an und für sich gehen oder?

Ja.
 
gni   Nutzer

12.04.2006, 18:16 Uhr

[ - Direktlink - ]
Thema: PicassoIV kein Bild über Flickerfixer mit Z4 Board + Videoslot-Adapter
Brett: Amiga, AmigaOS 4

Zitat:
rbn:
Bei mir lief es ganz einfach noch nie. Und das seit 3.1.

Aktuelle gtlayout.library in LIBS:?
 
gni   Nutzer

12.04.2006, 15:23 Uhr

[ - Direktlink - ]
Thema: PicassoIV kein Bild über Flickerfixer mit Z4 Board + Videoslot-Adapter
Brett: Amiga, AmigaOS 4

Zitat:
rbn:
Lass von dem TNG besser die Finger. Das ist buggy und läuft nicht auf allen Konfigs, zumal es dir keine Zusatzoptionen bietet.

Picasso96modeTNG ist die _einzige_ Möglichkeit den FF zu programmieren.

Was für Probleme gibt es denn mit dem Programm?
 
gni   Nutzer

12.04.2006, 09:08 Uhr

[ - Direktlink - ]
Thema: PicassoIV kein Bild über Flickerfixer mit Z4 Board + Videoslot-Adapter
Brett: Amiga, AmigaOS 4

Zitat:
Pro2-2001:
Das Einschaltbild mit der Diskettenanimation sehe ich über den angeschlossenen 19" iiyama Monitor.

Sowas bekommt man doch nur zusehen, wenn kein Boot-Device gefunden wird... Aber wenn Du das über den per PIV angeschlossenen Monitor sehen kannst, dann funktioniert der Video-Slot.
Zitat:
Ich kann zwar die Workbench 3.9 booten mit Picasso96 1024x768 aber sobald ich einen PAL Screen öffne kommt das Bild nur über den Amiga-Monitor-Ausgang.
Das Phänomen habe ich noch nicht gesehen. PASSTHROUGH klingt jedoch als mögliche Ursache.
Zitat:
Ich habe hier im Forum etwas gelesen über ein Picasso Programm wo man den Flickerfixer der PicassoIV einstellen kann.
Den FlickerFixer kann man mit Picasso96pmtng progammieren. Die Einstellungen des FF sind aber brauchbar, ansonsten gäbe es die Animation nicht oder auch kein Early-Startup-Menu.
Zitat:
Musicman:
es gibt ein Program was über die Workbench im Prefs die Daten vom FliFi verändern kann, ich glaube es hies PVS oder so ähnlich.

Damit kann man nur die ENV: Einstellungen von P96 und Tooltypes des PIV-Monitors ändern.
 
 
Erste 3 4 5 6 7 -8- 9 10 11 12 13 >> 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.
.