Comment insérer un .o à la compilation

Bonjour,

C'est difficile de répondre sans voir le projet ni comment tu compiles. Ce que je peux te dire, c'est qu'on partage rarement un .o tout seul, généralement une librairie est constituée de plusieurs .c, qui engendrent plusieurs .o, lesquels sont réunis dans une librairie (.so sous Linux, .dll sous Windows).

Quelques rappels avant de rentrer dans le vif du sujet :

• Compilation :
  • Les .h ne servent qu'à déclarer. Cela permet de contrôler, lors de la compilation d'un .c, que toutes les fonctions sont déclarées. Le .h n'implémentant pas ces fonctions, ces symboles sont mis en suspend jusqu'au linkage.
  • Les .c servent à implémenter des fonctions. Une fois compilé, un fichier .c engendre un .o.
• Linkage : on rassemble tous les binaires (.o, .so) pour produire le binaire final (soit un exécutable, soit une librairie .so, soit un module noyau .ko).
  • Si un symbole est implémenté dans plusieurs binaires intermédiaires, le linkage échoue (définition multiple).
  • Si un symbole est déclaré mais pas implémenté, le linkage échoue.
  • Si tous les symboles sont résolus une et une seule fois, la compilation réussie.

Dans ton cas, plusieurs explications sont possibles :

• le .o qui implémente les fonctions manquantes n'a pas été passé au linker
• le .o n'expose pas les symboles déclarés dans le .h (par exemple parce que tes fonctions sont précédées du mot clé static)

Après pour faire "proprement" ce que tu veux faire, il faudrait plutôt compiler une vraie librairie dynamique (.so ou .dll) et la livrer avec les .h correspondants. Afin d'avoir quelque chose conforme à ton système d'exploitation (notamment pour que les .h / .so soient déployés aux bons endroits), il est fortement recommandé de produire le Makefile à l'aide de cmake.

Bonne chance

Merci pour ta réponse, mais je vais essayer d'apporter un peu plus d'éléments pour que ce soit plus compréhensible.

Alors pour ma "librairie", la cible n'est pas un PC (donc pas de Windows, Linus ou autre), mais sur un microcontrôleur (NXP) et je développe un projet sur l'IDE S32 Design Studio (pour info).

J'avais déjà fait l'expérience, ou j'avais ajouté à mon projet, un .h et un .o (le .h fournissant les appels de fonction du .o) , et cela fonctionnait.

Et là j'ai essayé de réitérer l'opération, mais impossible, à la compilation (tout au moins au linkage) il me dit qu'il ne connait pas les fonctions. Et bien sur impossible de me rappeler ce que j'avais bien pu faire, alors que de mémoire, je n'avais rien fait de compliqué.

C'est pour ça que je me renseigne, pour savoir si pour le .o, je dois le déclarer (l'inclure) quelque part.

Merci

Salut amfrey95,

On ne connaît pas ton microcontrolleur ni ton EDI ou compilateur et son implémentation spécifique du C qui doit certainement fonctionner avec un système de build spécifique à ta plateforme.

Une chose simple que tu pourrais faire serait d'inclure dans l'arborescence de ton projet ta "bibliothèque" sous forme source, c'est à dire ton fichier ma_biblio.c et ma_biblio.h, afin que le fichier ma_biblio.c soit compilé avec le reste de ton code pour créer ma_biblio.o et le lier au reste de tes fichiers objet lorsque tu génères ton exécutable.

Pour cela, la plupart du temps pour les EDI, il ne suffit pas de copier les fichiers .c et .h dans le répertoire du disque dur (il ne faut pas le faire), mais il faut les ajouter à l'arborescence du projet via les menus de l'EDI. Si tu n'es pas sûr de comment ajouter des fichiers sources existants, crée des nouveaux .c et .h vides dans ton projet et copie-colle le code dedans (tu dois avoir dans ton EDI un menu du genre Projet - Créer - Nouveau fichier .c/.h).

Le code utilisant les fonctions de ta "bibliothèque" devra seulement faire un include du type #include "ma_biblio.h" (avec des guillemets), pour que le .h puisse être trouvé à la racine de ton projet.

Merci pour ta réponse, et je vais compléter sur la description de "comment je fais"

Donc j'ai mon projet qui compile, qui tourne. A ce projet, j'ajoute un nouveau fichier .c et .h. Dans le fichier .c, je crée une fonction toute bête qui additionne les 2 variables et retourne le résultat :

unsigned short FctTest(unsigned short u16Data1, unsigned short u16Data2)
{
  unsigned short u16DataRet = 0U;
  
  u16DataRet = u16Data1 + u16Data2;
  
  return (u16DataRet);
}

Dans un autre fichier .c, j'inclue le fichier .h (dans lequel j'ai déclaré la fonction en extern), et j'appelle la fonction FctTest (avec deux valeurs).

Je compile et ça fonction parce que le retour de la fonction me donne le bon résultat.

Jusqu'à là, tout va bien. Maintenant, je supprime le fichier .c (qui contient la fonction FctTest) et je mets le fichier .o (compiler avant) au même endroit que celui du .c (et .h) et je le laisse aussi dans le répertoire de compilation.

J'inclue même dans mon projet, le fichier .o. 

Mais lors de la compilation, (au moment du linkage), le compilateur me dit qu'il ne connait pas la fonction FctTest.

Donc je voulais savoir, si dans ce que j 'ai décrit, ce qui ne va pas, faut-il dans un fichier inclure le .o ou autre ?

Merci

Ton système de build n'utilise pas le fichier .o car tu as supprimé du projet le fichier .c correspondant.

Pourquoi ne veux-tu pas faire comme je l'ai proposé ?

Avec ton exemple, cela donnerait ceci avec 3 fichiers dans ton projet :

"main.c" :

#include "ma_biblio.h"

/* adapte le prototype du point d'entrée main() selon les 
 * exigences de ta plateforme si int main(void) n'est pas 
 * approprié (et le return 0 si nécesssaire) */

int main(void) {
        unsigned short u = FctTest(1, 2);
        /* faire quelque chose avec u */

        return 0;
}

"ma_biblio.h" :

#ifndef MA_BIBLIO_H
#define MA_BIBLIO_H
  
unsigned short FctTest(unsigned short u16Data1, unsigned short u16Data2);
  
#endif /* MA_BIBLIO_H */

"ma_biblio.c" :

unsigned short FctTest(unsigned short u16Data1, 
                       unsigned short u16Data2) {
  unsigned short u16DataRet = 0U;
  
  u16DataRet = u16Data1 + u16Data2;
  
  return u16DataRet;
}

Tu compiles ton projet en t'assurant que les deux fichiers .c sont bien compilés et pris en compte par le système de build de ton EDI.

Maintenant que ton ma_biblio.o est généré, à la prochaine compilation il ne devrait pas être de nouveau compilé, mais utilisé tel quel (à moins que tu modifies "ma_biblio.c" ou "ma_biblio.h"), mais ne supprime pas "ma_biblio.c" (ni "ma_biblio.h") de ton projet.

Sinon, j'ai trouvé ceci :

https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/mcuxpresso-ide%40tkb/478/1/How%20to%20create%20and%20use%20static%20library%20in%20MCUXpresso%20IDE%20-%20ver3.pdf

Mais c'est pour un autre IDE NXP :

https://www.nxp.com/design/software/development-software/mcuxpresso-software-and-tools-:MCUXPRESSO

Pour compléter les réponses de [Dal], rien n'empêche dans l'absolu de compiler un projet qui met en jeu des sources ".c" à compiler (disons fichier1.c et fichier2.c), et un ou plusieurs des ".o" (disons fichier3.c et fichier4.c) compilés auparavant. Il faut juste que les ".o" soient compilés pour la bonne cible. Dans l'absolu on ferait :

gcc -c fichier1.c
gcc -c fichier2.c
gcc main.c fichier1.o fichier2.o fichier3.o fichier4.o -o executable

Donc le problème de fond vient probablement de la manière dont tu compiles ton projet. Si tu passes par un IDE, celui s'attend plus probablement à ce que tu linkes avec un .so (disons libtoto.so), auquel cas la compilation se feraient ainsi :

gcc -c fichier1.c
gcc -c fichier2.c
gcc main.c fichier1.o fichier2.o -ltoto -o executable

Généralement, on ne s'embête pas à taper ces lignes à la main. Souvent on passe par un Makefile (peut importe qu'on soit sous Windows ou Linux, peu importe la cible). Et généralement, on ne s'embête pas à écrire le Makefile à la main (qui dépend du système d'exploitation), on le fait générer par cmake.

Bonne chance

Bonjour à tous, 

désolé du retard de ma réponse, donc concernant le lien sur l'IDE pour NXP, en ce qui me concerne, ce n'est pas le même IDE, cependant, j'ai trouvé la possibilité de créer une librairie.

Ca se fait très facilement, le seul truc, c'est qu'il ne faut pas oublié de mettre le même environnement que le projet qui appellera cette librairie.

Néanmoins, j'aimerai vraiment savoir comment j'ai pu faire pour que ça fonctionne avec le .o, mais bon, cette solution est plus "propre" que d'insérer des .o.

Merci à tous pour votre aide.