Tout est dans le titre !
 
Faut il une ou des directives speciale dans le code (.cpp) ou bien tout se joue-t-il dans les parametre de gcc ?
 
Est-ce bien l'equivalent d'une Dll mais pour unix ?
 
Et comment charger un fichier so pour l'utiliser dans une appli ?
 
Je sais ca fait bcp de questions ! J'accepte meme des cours !
 
Merci

la methode la plus simple
 
g++ -c -shared [-fpic] -o truc.so truc.cpp
g++ truc1.o truc2.o truc.so

Non, quand tu charges une bibliothèque partagée, c'est une opération de link (avec résolution des symboles).
Une Dll Windows utilise une table avec les éléments exportés "génériques" (cela peut-etre des pointers sur fonctions de natures différentes). Ca pose de problème quand tu veux exporter des classes. Par contre je crois que ce système est plus rapide
 

 
Au link de l'appli (comme n'importe quel .o). Il y a un moyen de charger une bibliothèque pendant l'exécution en connaissant son nom (comme LoadLibrary sous Windows), mais je connais pas les noms des fonctions (si j'en avais besoin et que personne ne savait, je regarderais dans les sources de xmms, vu qu'il charge des plugins).
 
Edit: la fonction c'est  dlopen (merci google), et la doc c'est  man dlopen

 
ok pour creer un .so a partir d'un cpp
si je veux creer un .so a partir de plusieurs .cpp et d'un autre .so, ca donne ca :
 
g++ -shared [-fpic] -o monFichierDeSortie.so titi.o toto.o tata.o -LcheminFichierSoAUtiliser -lfichierSoAUtiliser
 
 
[citation]
g++ truc1.o truc2.o truc.so
[/citation]
 
Ca c'est pour l'utilisation du .so ? Donc on peut acceder aux ressources de truc.so dans les fichiers truc.o et truc2.o ?
 
 
Je suis coté de le plaque ou pas trop ?

C'est presque plus rapide de tester que de poser la question :-)
Tu crees un .so qui a une fonction "toto" et tu essayes de l'utiliser dans ton programme... Ca doit prendre 2s

attention à la décoration de nom si tu compiles en C++ ton .so et que t'essaies de l'ouvrir avec dlopen... tu ne pourras accéder avec dlsym qu'aux fonctions "extern". si tu veux accéder à des classes, faut magouiller avec des fonctions factories "extern" ou avec des structures contenant des pointeurs.

Sous Windows, la notion de DLL correspond à la notion de module, avec partie publique / partie privée. D'où la liste des fonction importées et exportées d'une DLL.
Sous UNIX, la notion de SO (Shared Object) est une extension des librairies statiques (*.a) qui sont des librairies de code toutes bêtes. Autre ment dit, toutes les fonctions y sont publiques, et utilisable par une autre librairie ou programme.

 
il me semble que lorsque l'on veut créer une librarie dynamique sous *nix, on n'est pas obligé d'exporter tous les symboles en utilisant un fichier map lors du link.
Dans ce cas, les symboles non exportés ne sont pas accessibles si on charge la lib dynamiquement.