Bonjour à tous, je travaille en ce moment sur une application en C comprenant 2 bibliothèques, Mère et Fille. J'ai du mal à comprendre comment les compilations et les éditions de liens sont faites, pouvez-vous m'aider ?
 
On compile la Mère en dynamique : le but est d'obtenir Mère.so. Lors de l'édition de liens de Mère, on inclut Fille en statique, donc Fille.a (une archive).
 
J'étais donc parti pour compiler les sources de la Fille avec (grosso modo)
> gcc -c fille*.c -o fille*.o
> ar rv Fille.a fille*.o
 
Puis inclure Fille.a lors de l'édition de liens de la Mère :
> ld -shared mere*.o Fille.a -o Mere.so
 
Ce à quoi on m'a rétorqué : "Non non, c'est une compilation dynamique, donc on 'archive' bien les fille*.o 'dans' Fille.a, mais la compilation des sources se fait avec le flag -shared :
> gcc -shared -c fille*.c -o fille*.o
> ar rv Fille.a fille*.o (cette commande ne change pas)
"
 
Moi j'ai du mal à comprendre le truc... je pensais qu'on produisait une archive pour "faire" du statique, et un shared object pour "faire" du dynamique, mais mes notions ne sont pas très claires. Ensuite, il faut lors de l'éxecution mettre l'emplacement des .so dans le LD_LIBRARY_PATH, alors que c'est inutile pour l'archive.
 
Or là je vois que dans mon projet, on utilise l'archive "hybride" (qui contient des objets compilés en -shared) comme une archive "classique", rien de la Fille n'est inclus dans le LD_LIBRARY_PATH, on n'y trouve que le chemin vers Mere.so.
 
Quelqu'un pourra t-il m'éclairer ? Merci.

Tu as raison.
La ligne gcc -shared -c fille*.c -o fille*.o produit un fichier objet pour une bibiothèque partagée, donc externe ou dynamique. L'archivage de ce fichier devrait se faire dans ".so" au lieu d'un ".a".

Le man de gcc recense le flag -shared dans la catégorie 'Linker options', dont il dit "These options come into play when the compiler links object files into an executable output file.  They are meaningless if the compiler is not doing a link step."
 
Donc en théroie, si tu fais un gcc -shared -c file.c, ça revient strictement au même que de le faire sans le -shared. Sauf qu'en pratique j'ai bel et bien une différence à l'execution.

 
Et quelle est la différence à l'exécution ?

En l'occurence, un SegFault. Mais je ne pourrai pas te dire quelle en est la raison, je n'intervient sur le projet que pour faire un portage, donc je n'ai pas étudié le source.
 
Par contre derrière, j'ai écris un simple programme de test, test.c, avec une fonction toute con. J'ai compilé avec et sans le flag -shared, et les 2 binaires obtenus étaient identiques.

Que donne l'analyse post-mortem ?
 

Si tu parles bien des fichiers objets, c'est également ce que je m'attends à trouver d'après la documentation.

C'est-à-dire, tu veux quoi comme données ?
 
En fait c'est ma première "grosse" compil sous Linux (et je suis gâté), je viens plutôt du monde Windows.

compiler en debug :  
$ gcc -g *.c
lancer et voir se vautrer l'appli :
$ ./a.out
analyse post-mortem à partir du core généré :
$ gdb a.out <nom_du_core>
--> bt
 
 

On avait justement ce problème, c'est que l'application ne plantait pas en mode débug. La raison : le plantage se manifeste lorsqu'il y a l'option -shared, mais seulement si on place également le flag d'optimisation -O2.
 
Or en débug on n'optimisait pas (-O0), du coup pas de plantage. Mais c'est vrai, c'est une bonne idée, je pourrai essayer de compiler en debug -O2, faire planter l'appli et tracer l'erreur.
 
Mais pas maintenant, lundi