GCC déboire

[Gofromiel]

Gofromiel

#4188

Crotte de mouche ! Je viens de passer 3H à me battre avec GCC et make. J’arrive sans problème à compiler des applications pour Feelin, mais alors feelin.library et les classes c’est une autre paire de manches, et là j’en ai marre

La compilation se passe sans trop de problèmes, à part quelques warnings que je règles immédiatement (c’est Yomgui et Hombre qui vont être contents). Une fois toutes les parties de la classe compilées, c’est le « linkage » qui pose problème. Le voici merveilleux:

Je « linke » avec « -noixemul -nostartfiles ». Et là « libnix » demande le symbole « ___UtilityBase » ! La pute ! « _UtilityBase » est définie, puisque la bibliothèque est utilisée par la classe, mais pas « ___UtilityBase » !! C’est quoi ces conneries ?? Et pourquoi elle en a besoin d’ailleurs ? Pour des DIVISIONS !! Alors que j’ai compilé le tout avec « -m68020 ».

J’ai tout essayé: avec, sans, dessous, derrière. C’est triste.

J’utilise GCC 2.75 (livré avec CubicIDE). Si quelqu’un pouvait m’aider, je l’aimerai toute ma vie.

Merci :!!

/gofromiel brulé :sweat:

[Yomgui]

Yomgui

#73806

C’est pas GCC le pb… c’est ta libnix…

apparement il doit y avoir un symbol __UtilityBase (avec 2 _) qq part, et comme sur 68k on rajoute un _ sur tous les symbols tu dois te retrouver avec 3 _.

Maintenant tu peux linker avec « -Wl,-Map=T:map » apres gcc, tu auras le map file dans T:, de la tu peux voir qui demande ce symbol. Autre solution: dumper les symbols non definis avec « nm -g –undefined-symbol Path_to_lib/libxxxx.a » pour voir qui a besoin de ce symbol.

[Gofromiel]

Gofromiel

#73807

C’est très pratique choups, mais ça ne règle pas le problème ‘___UtilityBase’ n’y apparaît même pas, et pourtant:

/gg/lib/libnix/libnix.a(__udivsi3.o)(.text+0x14): undefined reference to `__UtilityBase’

/gg/lib/libnix/libnix.a(__mulsi3.o)(.text+0x8): undefined reference to `__UtilityBase’

Pff ! C’est nul ! Je viens de compiler la classe Element pour voir et ça marche très bien. Du coup je suis content et je suis pas content. Le problème vient de atol(). Mixed Feelings Sinon je peux toujours réécrire atol(), c’est fastoche, mais j’ai pas envie de me taper toute les fonctions standards non plus :'(

/me pense qu’il va aller ennuyer Corto

[Fab1]

Fab1

#73808

linke avec -lm peut être.

[Alex]

Alex

#73809

@Gofromiel

à mon avis l’implémentation de tes fonctions de conversion utilise Utilitylibrary pour faire les conversions pour prendre en compte la locale de ton système (au hasard le point décimal et tous les confrères de séparateurs) pour pouvoir accepter les formats dans la langue par défaut du système… Enfin ce que j’en dis… Du coup si tu les réécris, bhein faudra te palucher à la main tout ça parce que sinon bhein ça risque de bien marcher sur ton système français, mais pas du tout sur un système Anglais, Hongrois ou autre…

[corto]

corto

#73810

Grofomiel : Ca ne m’ennuie pas du tout, le problème c’est que je ne pense pas être le mieux placé .. Yomgui et Fab doivent bien mieux connaître les entrailles des compilos.

Mais j’ai déjà eu un problème similaire … j’avais galéré avec les libs math sur 68k. Le support n’est pas forcément pareil suivant les compilos, les processeurs, l’utilisation d’ixemul ou pas (je crois), …

Comme dit Fab, peut-etre que -lm résoud le problème. Et il faut faire attention à l’ordre des libs que tu linkes.

J’ai un vieux projet dans lequel il faudrait que je jette un oeil, j’y regarde ce soir.

Sinon, tu as essayé avec vbcc ?

Enfin, quitte à compiler sur 68020 mini, il me semblait que l’option -m68020-60 donnait de très bons résultats (meilleurs sur 060 et pareils sur 020).

[Gofromiel]

Gofromiel

#73811

Pff. Rien n’y fait, « -lm » ne change rien du tout :'( Tant pis. Du coup j’ai crée ma propre atol(), et maintenant il me demande bcopy()…

Je vais au cinéma voir Paprika, ça me changera les idées.

++

[corto]

corto

#73812

Mince

Je me proposerais bien d’essayer chez moi mais j’ai déjà du mal à avancer dans mes projets. Tiens, je vais uploader ce soir un portage (partiel) de Ruby pour OS4.

Tu pourrais poster ton problème sur utilitybase.com, non ?

Mais il faut faire un break, tu vas peut-être revenir dessus et paf, la révélation ! Moi je suis allé voir Muse à Lyon hier et aujourd’hui c’est la grosse pêche !!! (en plus il y a Hugh Grant à la télé )

Allez, demain, on rattaque ton problème.

[Gofromiel]

Gofromiel

#73813

Merci maître corto, vous êtes superbe. On dit que la nuit porte conseil…

[Gofromiel]

Gofromiel

#73814

Bon, j’ai pas pu résister à l’envie de mis mettre… Je viens de découvrir une chose fabuleuse: si j’ai le malheur d’inclure «  » le linker se plain que « NewObject » est défini dans chacun des objets (*.o) qui composent la classe !? L’include «  » créerait-elle des objets BOOPSI pour le plaisir infini de me faire chier ?

Vraiment, c’est un mystère :'(

[henes]

henes

#73815

Pas de proto/ dans une lib… sauf lorsque l’on sait très exactement ce que l’on fait.

Regarde la définition de cette « fonction » et tu comprendra surement pourquoi tu as un symbole NewObject dans chaque .o.

Utilise plutôt NewObjectA().

[Yomgui]

Yomgui

#73816

Henes: ouai pas de proto dans les libs! (pas faire comme moi qui sait toujours ou il va… enfin je pense…)

Gofro: inline… Les proto inclus des inlines des fonctions sauf si tu definis _NO_INLINE et celui-la aussi pour PPC: _NO_PPCINLINE. Ca vaut pour les includes AOS3 et MOS. Je ne sais pas pour AOS4

[Alex]

Alex

#73817

Pour OS4, par défaut tu n’as plus d’inlines, tu as pour chaque librairie une structure C contenant des poitneurs de fonctions (en fait pour être tout à fait exact c’est une par interface de la library), d’où les appels IDO->Open() ou IExec->CreateMsgPort()… Enfin sauf si tu définis __USE_INLINE__ ou là comme sont nom l’indique tu retombes dans les inlines qui sont définis ainsi : #define Open(name, accessMode) IDOS->Open(name, accessMode) .

voili, voilou.

[Gofromiel]

Gofromiel

#73818

Alors: _NO_INLINE: Ne change rien au problème de « NewObject », par contre ça désactive les fonctions vargs de Feelin comme « F_Do() ».

Du coup je me suis dis : « tient ! ben pourquoi ça marche comme sur des oeufs avec Feelin et ça chie avec Intuition ? »

J’ai jeté un oeil, et voilà. J’ai remplacé:

__inline APTR NewObject(struct IClass * classPtr, CONST_STRPTR classID, ULONG tagList, …)

{

return NewObjectA(classPtr, classID, (const struct TagItem *) &tagList);

}

Par (comme pour Feelin)

#define NewObject(__p0, __p1, …)

({uint32 _tags[] = { __VA_ARGS__ };

NewObjectA(__p0, __p1, (struct TagItem *) _tags);})

Et, magie de la vie, ça marche !!

Du coup je ne sais pas quoi faire…

[henes]

henes

#73819

Regénérer tes includes avec un meilleur outil.