Version du C dans le SDK de MorphOS 3.7 ?
15 sujets de 1 à 15 (sur un total de 15)
-
Bonsoir à tous,
J’essaye de porter du code C99 que j’ai écrit à l’origine sur Windows et sur Linux (Debian 7.7 PPC sur iMac G5). Le portage de Windows vers Linux s’est relativement bien passé, GCC sur Linux a accepté mon code sans trop de souci.
Par contre, sur MorphOS, GCC me pose nettement plus de problème. J’utilise des sources publiques OpenAES pour du chiffrage AES en complément de mon code. L’utilisation de phtread ne semble pas supporté (pas de phtread.h dispo sur MorphOS et celui que j’ai trouvé sur le web ne passe pas, il semble aussi écrit en C99) et j’obtiens même un message du compilateur « Please upgrade your GNU compiler to one that supports __declspec. »
J’avoue que par rapport à CodeBlocks sur Linux, c’est vraiment le parcours du combattant. Par contre, on m’a dit que sur StormC 5 sur OS 4.1, ça passait nettement mieux, à voir…
Si vous avez une astuce pour débloquer la situation, par avance merci et bon week end à tous !
Pierro
Merci pour l’info, effectivement, je compilais avec la version 2 de gcc, qui ne reconnaissait pas une partie du code C.
Je viens de refaire l’essai avec la version 4 et là, plus de souci, tout passe comme sur Linux ou Windows. Par contre, j’ai un petit souci avec la powerSDL à laquelle je fais appel puisque quand je linke la librairie avec mon fichier, j’obtiens l’erreur: « undefined reference to ‘SDL_RWFromConstMem’. Après recherche sur Google, il semblerait que la powerSDL n’implémente toujours pas cette fonction, même dans la dernière version 16.1 (sortie en décembre).
Y-a-t-il une solution pour contourner le problème ?
Par avance, merci pour toute info que vous auriez, bon week end à tous,
Pierro
Je me réponds à moi même, j’ai réussi à trouver les fonctions manquantes dans le code source de VLC pour MorphOS, du coup, je les ai ajoutées dans mon programme et tout compile bien, y compris le link avec les librairies .a
Par contre, l’appli se lance sans problème, mes printf de test dans le main affichent les bonnes valeurs mais la fenêtre SDL ne se lance pas…aucun crash ou message d’erreur. Je précise que j’ai linké les objets .o avec la libSDL.a et SDL_image et smpeg au moment de la compilation.
Ca se mérite de faire fonctionner ses programmes sous MorphOS !
Je viens de faire divers tests avec des sources publiques de logiciels MorphOS utilisant la SDL et je rencontre le même problème à chaque fois. A priori, je loupe quelque chose au moment du link avec la bibliothèque SDL. Par exemple: ppc-morphos-gcc-4 sdldemotools.o fire.o main.o -o fire -lSDL
Le compilateur crée bien l’executable « fire » sans aucun message d’erreur ou warning mais lors de l’éxécution, aucune fenêtre SDL ne s’ouvre…
Merci d’avance pour vos infos sur la compilation et le link de librairie sous MorphOS…
Bon problème réglé, tout marche super… (à part les vidéos mpeg1 décompressées par la bibliothèque smpeg mais c’est un détail qui rester à régler). Pour ceux qui rencontreraient le même problème plus tard, il faut compiler avec l’option:
ppc-morphos-gcc-4 main.c -o sdl_morphos -lz
sdl-config --cflags --libs-lSDL_image -lSDL_ttf lsmpegLe script sdl-config est obligatoire pour linker correctement la SDL.
J’utilise un mac mini G4 1,4 Ghz avec 512 Mo de RAM. Lors de l’execution du programme qui affichent des spritesheets d’animations 3D, des animations d’images, des images fixes, du fading, et des vidéos à partir de données compressées et chiffrées en AES 256 bits, je suis sensiblement a des performances inférieures à un imac G5 2Ghz / 2Go de RAM qui ne montre aucun ralentissement. Ceux qui ont une machine MorphOS peuvent me demander le programme pour comparer leurs performances. Le tout fait moins de 10 Mo.
Je vais procéder à l’adaptation des sources sur AmigaOne500 Sam 460 sous OS 4.1 pour voir ce que ça donne. Par contre, pas d’espoir que ça fonctionne sur un classic vu les performances limites que j’obtiens sur un Mac mini.
Bon week end à tous !
Pierre
Il faut compiler ET linker avec l’argument -noixemul.
Sans cela, on crée un exécutable utilisant la ixemul.library qui est un environnement « presque-Unix » ne permettant pas d’utiliser les autres bibliothèques partagées, dont powersdl. ixemul est en gros prévu pour compiler gcc, grep et autres unixeries.
sdl-config ajoute cet argument et bien d’autres.
Merci pour tes infos, ça m’aide bien car il y a bcp moins d’infos sur le dev MorphOS que sur OS 4.1 sur Google.
Une dernière question… Lorsque je compile et linke mon executable avec les différentes bibliothèques (SDL, SDL_image, SDL_ttf et smpeg), tout se passe bien, les animations sur spritesheeets fonctionnent sans problème, par contre, aucune vidéos MPEG1 ne passe en lecture alors que le code fonctionne sans problème sur Debian 7.7 PPC (vidéos mpeg comprises).
La lib smpeg statique smpeg.a fournie avec powersdl fonctionne vraiment ? Et si non, comment linker mon executable avec la version partagée .library plutôt que la version statique .a ??
Lorsque je fais -lsmpeg en spécifiant la repertoire avec -L où se trouve la bibliothèque partagée, gcc me dit toujours qu’il ne trouve pas de bibliothèques smpeg alors que ça ne pose aucun problème avec le répertoire ou se trouve la version statique .a
Il faut peut être faire une manip avec la bibliothèque smpeg pour la déclarer sur MorphOS ?
Merci pour ton coup de main en tout cas. Pour le chiffrage AES, c’est plus pour tester, tu peux trouver les sources dans le projet openAES.
Pierre
Merci pour tes infos, ça m’aide bien car il y a bcp moins d’infos sur le dev MorphOS que sur OS 4.1 sur Google.
Tu peux aussi chercher des docs sur AmigaOS, c’est la même chose et les infos restent valables pour MorphOS. Ainsi le « Dev CD » est bourré d’infos pertinentes, par exemple.
Sinon, AmigaOS/MorphOS n’est pas Unix… Les bibliothèques ne sont pas des .so bourrés de symboles. Tu ne peux pas linker un .library
Chez nous, les appels de fonction sont en fait des sauts à un offset relatif à une (library) base. Le linker ne peut pas deviner l’offset…
Les includes contiennent donc des macros portant le nom des fonctions. Quand tu fais SMPEG_new(), tu passes en fait par une macro qui fait le saut que je mentionne. Cela a plein d’avantages mais aussi l’inconvénient de ne pas être comme Unix :-pIl existe aussi une autre méthode (via -D_NO_PPCINLINE sur MorphOS) qui consiste à dire au compilo de ne pas passer par ces macros. A la place, tu auras vraiment un appel au symbole SMPEG_new dans ton fichier objet.
Les « .a » que tu peux trouver dans le SDK PowerSDL font principalement deux choses :
1) ouvrir automatiquement le .library si tu as un source non adapté à nos OS (où tu controles manuellement l’utilisation de la bibliothèque à travers OpenLibrary()/CloseLibrary())
2) fournir des « stubs » qui font les vrais appels (comme une fonction SMPEG_New() qui va faire le saut dans le code de la .library) si tu as compilé dans ce mode
En gros, le smpeg.a fourni est en fait un wrapper te permettant de compiler pour la smpeg.library… sans avoir à changer ton source (bon en fait je dis cela mais je n’ai rien vérifié… c’était en tout cas l’idée originale quand on a fait ces libs powersdl et j’imagine qu’itix a continué sur la même voie. C’est aussi comme ça que fontionne l’utilisation de toutes les bibliothèques opensources adaptées à MorphOS comme la libpng etc…)Sinon, aucune idée si la smpeg.library fonctione…
J’imagine que oui mais on ne sait jamais.
La première chose à vérifier dans ce cas est si la bibliothèque est bien trouvée et ouverte avec succès (peut-être qu’elle dépend elle même d’une autre ressource manquante).
Tu peux pour cela utiliser SnoopDos ou Snoopium. Ce dernier étant inclu dans MorphOS (voir SYS:Tools/).
Ils vont te dire qui ouvre quoi (ou pas) dans le système. Merci henes pour toutes tes infos.
Concernant la smpeg, Snoopium m’indique que la librairie est bien ouverte et chargée lors du lancement de mon application, sans aucun souci. Les infos sont d’ailleurs similaires à la powersdl qui elle fonctionne sans problème.
Du coup, je commence vraiment à me demander si cette librairie smpeg n’a pas un souci car je vois qu’il y avait déjà un bug d’initialisation qui a été corrigé dans la dernière version.
J’ai essayé de recompiler la librairie depuis ses sources mais comme tu l’a indiqué, Morphos n’est pas Linux et le compilateur remonte plusieurs erreurs avec g++. N’étant pas un as du C++, je préfère laisser cette option de côté car modifier des sources pour les rendre compatibles avec un OS demande quand même pas mal de travail.
Du coup, je vais essayer de trouver une autre librairie mpeg car je vois que mplayer sur MorphOS par exemple lit mes vidéos sans aucun problème.
Bonne journée !
Pierre
A priori, la seule autre bibliothèque disponible pour le développement (mais seulement pour OS 4.x) serait la libmpeg2 qui semble avoir un mode de fonctionnement très proche de la smpeg. J’attends de recevoir OS 4.1 FE avant de tout adapter sur cette plateforme.
Il n’y a aucun moyen de lire une vidéo MPEG2 sur MorphOS via une librairie ?
Bonne journée à tous,
Pierre
Ces « erreurs » de compilation C++ sont sans doute faciles à corriger, mais ceci dit, si tu préfères te lancer sur la libmpeg2, c’est encore plus simple : cette lib se compile très facilement sous MorphOS. La libavcodec/ffmpeg est aussi une bonne alternative, qui se compile assez simplement aussi (le player HTML5 d’odyssey est basé dessus, de même que MPlayer).
Le problème de la smpeg, c’est que c’est une librairie conçue sur Linux et pour Linux. Du coup, on trouve dans les sources plusieurs appels de fichiers headers spécifiques à Linux qui ne sont pas forcément dispo sur MorphOS et AmigaOS (et ni même Windows au passage).
Par ailleurs, la décompression MPEG2 et les performances sont quand même meilleure que pour MPEG1 et passent sans problème sur PPC. Je regarde tout ça.
Bonne soirée,
Pierre
15 sujets de 1 à 15 (sur un total de 15)
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Développement › Version du C dans le SDK de MorphOS 3.7 ?
