Le probleme est simple quand j'essaye de faire un shared library sous solaris, le linkler ne trouves plus les templates qui sont definis et utilisées dans la shared Library.
 
Si je fais une statique ca marche nickel !
 
Bien sur, cela marche sur toutes les autres plates-formes...
(sauf Win, mais là c'est normal...)
 
Si quelqu'un à une idée

 
T'as pas un petit exemple de code (court) pour voir un peu de quoi il retourne?

 
Ben le code est plutot long, mais il marche a merveille sur toutes les autres plates-formes UNIX...
 
Le principe :
J'ai une classe template dans le style STL. qui n'est utilisée que dans la shared library. La shred Library à une interface C, et elle est destinée a etre linké à du C...
 
Mais au moment du link j'ai des "undefined symbol"  qui apparaissent, ceux-ci n'apparaissent pas sur les autres plateformes, ni si je link directement...
 
Normalement en Unix il n'y a pas de différence que le code soit destiné a etre en shared lib ou en static lib...

 
Je suis d'accord, il n'y a pas de différence de code. Par contre, il y a une différence puisque lorsque tu fabriques une lib dynamique, il faut spécifier les symboles à exporter, ce que tu n'as pas à faire avec une lib static.
 

 
A quel moment se pose le problème? Quand tu crées la librairie dynamique elle même, ou quand tu link le programme C avec cette librairie. Ta description pas très explicite. Des précisions s'imposent!

Pardon ?
Sous Solaris il faut faire comme en Windows ?
Je n'en crois rien...
Quand je fais des Shared library sans templates sous solaris je n'ai aucun problème...
 

Le message arrive au moment de l'execution, c'est a dire quand la Shared Library se link dynamiquement avec l'executable...
Les classes Templates n'étant definies que dans la shared Library, et n'ayant aucun Pb en Link statique, c'est que le Pb viens a mon avis du link de la shared library (bien qu'il n'y ai aucun message a ce moment là). Un nm montre que les methodes des classes considérés sont effectivement UNDEF...

>Pardon ?
>Sous Solaris il faut faire comme en Windows ?  
J'ai jamais dit ça!
 
> Quand je fais des Shared library sans templates sous solaris je n'ai aucun problème...  
 
Sans doute parce que souvent, quand tu crées une lib dynamique sous unix, le linker exporte de lui même tous les symboles. Ou alors c'est que lui spécifies les symboles que tu exportes. Bref...
 
Bon, une autre question importante: quel compilateur? (parce que j'avais eu des pb avec des templates dans des libs dynamiques avec CC et pas avec gcc...)

Comment lui specifier les symboles que l'exporte, ca je ne sait pas faire mais ca m'interesse, ca devrait reduire le temps de chargement (c'est pas que ce soit long, mais bon si c'est facile ca ne peu pas faire de mal et ca homogeneiserais avec WINDOWS)...
 
le compilo : SC6 (CC en ligne de commande)

 
si tu utilises ld avec solaris 2.8, alors tu peux créer un .map qui contient tous les symbloes à exporter. Ce fichier contient qqchose du genre:
 
VERSNUM {
 global:
 MySymbol1;
 MySymbol2;
 
 local:*;
};
 
et ensuite, quand tu appelles ld, tu spécifie ce fichier avecx l'option -M qui sert à spécifier un fichier de map. (Note: on peut faire la même chose avec visual en spécifiant les symbloes à exporter dans un fichier .def).
 
 

 
alors moi j'avis mes pbs en utilisant l'option -instanciate=static  de CC lors de la compilation du code. Regardes dans la doc de CC à propos de cette option pour plus d'infos ;-)
 
 
En esperant que tout cela t'aide.

Arggg. Fo se relire avant de poster:
 
alors moi j'avais résolu mes pbs en utilisant l'option -instanciate=static  de CC lors de la compilation du code.
 
C'est mieux comme ça!

Et du coup tu faits des instanciations manuelles ?
Parce que si je pars par là j'ai pas fini !

De mémoire, c'est effectivement la méthode la plus simple (et bourrine) : instancier un objet de chacune des classes templates susceptibles d'être utilisées à l'extérieur de la librairie partagée.

 
nan, c'est pas ça. En fait, pour essayer d'optimiser le code, le compilateur ne génère pas le code des template car il se dit que d'autres lib au le prog principal le feront. Et donc, les templates ne sont pas compilés et le linker doit donc les résoudre. Mais si ces fonctions templates ne sont compilées dans aucune lib ni dans le prog principal, alors il y a des erreurs d'unresolved.
Dans ce cas, utiliser l'option -instanciate=static permet de forcer la compilation de ces templates en disant explicitement qu'ils doivent être instancier dans le code qui est en train d'être compilé.
Donc normalement, tu n'as rien besoin de changer dans ton code. Rajouter cette option lors de la compilation ( et pas du link ) devrait suffir.

 
Je n'ai pas compris le problème de cette façon. Tu ne peux de toute façon pas exporter une classe template, puisqu'une classe template doit toujours être connue au moment de la compilation (declaration et implementation).
Je ne comprends donc pas bien quel sens cela peut-il avoir d'exporte r une classe template dont on ne se sert pas dans la librairie même. Tu peux préciser ton point de vue?

Bon en fait mon systeme de Build appelait directement ld en non CC du coup les templates n'étaient pas linkés dans la shared lib...
 
Apres m'etre battue avec le systeme de Build je suis arrivée au point ou les templates sont là...   mais en double
 
utilisant l'option verbose de CC lorsqu'il est appelé pour linker, on vois qu'il appelle ld en lui passant  les fichier des templates en double : une fois avec  le path absolu, une fois avec le path relatif...
 
forcement ce n'est pas du gout de ld...