Hello
 
Dites j'ai un problème avec ce langage archaïque qu'est le C   .
Bon je ne suis pas doué non plus cela dit
 
Bref le compilo, semble avoir du mal à trouver des fonctions pourtant bien définies.
 
En gros c'est simple.
Dans mon main.c j'utilise une lib quelconque.
 
Dans ce main.c j'ai donc un #include malib_config.h, ce même fichier se trouve dans le même dossier que le main.c.
Le header malib_config.h contient: #include "monDossier/ma_lib.h".
Ce header ma_lib.h contient: #include "dossierXYZ/xyz.h"
 
C'est dans ce header xyz que mes fonctions sont définies.
 
Or le compilo me pond une erreur dans le main.c, il ne semble pas trouver les fonctions qui existent bien dans ce xyz.h.
 
 
Bref il y a un truc que j'ai pas capté avec les header files en C/C++.
 
Eclipse lui s'y retrouve très bien, CTRL + click sur le nom de la fonction et il m'ouvre son implémentation. Le compilo lui fait la gueule.
 
Une aide?
Merci

Faudrait voir les fichiers main.c et xyz.h

J'ai pas le droit de la mettre en ligne.
 
C'est la lib cryptographic pour STM32 de ST Micro.

C'est quoi exactement le message d'erreur ?
C'est à la compile ou au link ?

A la compilation.

Compilo:
GNU toolchain for ARM

Il manque des link.
 
Tu devrais avoir un fichier du genre libtralala.a (à placer dans le dossier lib du compilo, ou rajouter la dir à la main)
 
Si tu fais ton makefile toi-même :  
 
-L"LeCheminVersTaLib"
-ltralala (en admettant que ta lib s'appelle libtralala.a)
 
Sinon, faut voir selon l'IDE.
 
Après, si t'es pas avec une librairie externe, dans ce cas c'est que tu as un fichier *.c pas compilé.

 
Ca ressemble plutot à une erreur de link (et pas de compilation).
Comme dit au dessus il doit manquer les chemins des libs.
 

Merci pour vos réponses.

En fait je me rends compte qu'il n'y a que les prototypes des fonctions de définis, pas leur implémentations.
C'est quoi que cette lib  

Par contre quand j'ouvre le projet avec IAR Workbench (pour lequel un fichier project/workspace est fourni avec la lib), ca compile sans broncher.

Je viens de rajouter la commande -I.... comme vous me l'avez conseillé, et en effet je n'ai plus besoin d'utiliser le chemin complet vers le header file quand j'inclus dans un autre fichier, en gros le compilo sait les retrouver.
 
Par contre j'ai toujours ces undefined reference to
 
Je sais pas où elles sont implémentées ces fonctions , en principe c'est une demo toute fait, il y a qu'à compiler et c'est fait d'après la doc, pas besoin d'implémenter nous même ces fonctions prototype (encore heureux j'ai aucune idée de ce qu'elles doivent faire).

Donc il faut linker la lib.
Tu devrais avoir un fichier libxxx.a qui traîne quelque part, cherche-le et link-le (-lxxx )

Oui en effet j'ai un xyz.a dans un dossier Binary/EWARM (pour IAR Workbench donc) et un fichier xyz.lib dans un dossier Binary/MK-ARM (pour Keil MDK donc).
Par contre le fichier n'apas de préfixe "lib", ca ne posera pas problème?
 
 
Je vais essayer de voir comment on inclut la commande dans le makefile existant. Je suis obligé d'utiliser celui de ChibiOS, et c'est la jungle

Maintenant j'ai une avalanche d'erreurs au niveau de la lib elle même: undefined reference to `__aeabi_memcpy'....
 
J'imagine que la lib crypto a besoin d'une autre lib annexe que je dois charger avant?  
 
 
EDIT:
mmh, ou plutôt ca n'aime pas le compilo GNU gcc arm , ce qui explique pourquoi il y a des fichiers lib différents en fonction du compilo/environnement de dev.
 
Si j'utilise l'autre fichier .lib ca me donne un hidden symbol `__aeabi_memcpy' isn't defined

Il me semble que les fichiers *.lib c'est les librairies pour Windows, donc avec un compilateur de chez Microsoft.
 
Le fichier *.a devrait faire l'affaire, après j'ai jamais dev avec GCC Arm3.
 
Tu as une idée du compilateur utilisé pour les sources de test ?

J'ai pas trouvé cette info dans la doc, mais je dirais que le *.a est compilé par le compilo propriétaire d'IAR Workbench et le *.lib par celui de Keil.
Vive la jungle des compilo et leur implémentation différente .
 
Décidément faut un BAC+5 spécialisation système embarqué pour s'y retrouver dans ce bazar .
C'est pourtant simple ce que je veux développer et pourtant je perds 99% du temps à configurer ou a essayer de comprendre environnement de dev.
 
Bon ben je vais aller faire un tour sur le forum de ST.
 
 
En tout cas merci pour ton aide, ca m'a quand même permis d'avancer un peu vers la solution

Un utilisteur sur le forum ST m'a donné un shim pour rendre la lib compatible avec gcc.  
Ca compile maintenant.
 

Hello  
 
Encore moi, alors ca ne concerne pas la lib dont on a parlé plus haut, mais j'ai denouveau le même genre de problème de undefined reference to
 
Sauf que la je ne vois absolument pas d'où vient l'erreur. Pourtant c'est tout simple.
J'ai un sous-dossier Eeprom qui contient des headers, source et makefile.

 
Le eeprom.mk il est inclut dans le makefile principal et est correctement configuré.

 
Dans eeprom_testsuite.c je fais appel à des fonctions définies dans eeprom_i2c.h/eeprom_i2c.c
Le fichier eeprom_testsuite.c inclut le header hal.h qui lui même inclut eeprom_i2c.h
 
Je précise que EEPROMINC est placé au bon endroit dans le makefile, car si je mets un chemin quelconque c'est hal.h qui gueule, donc c'est que le chemin doit être ok.
Pour le EEPROMSRC, il est ok aussi vu que les fichiers .o sont bien générés.
 
Et pourtant ca me pond un undefined reference to  
 
Help please

Bon finalement il s'avère que c'est ca qui pose problème
 

 
En gros le contenu du header n'était pas lu à cause de cette condition.

 
C'est une protection contre les inclusions multiples, il faut surtout pas l'enlever.
 

Ah c'est donc ca. Je le rajouterai plus tard quand je me serai débarrasser des autres problèmes alors

En l'occurrence ca   :

unknown type name 'EEPROMConfig'
 

Si je rajoute "struct" devant comme je l'ai fait pour l'autre structure, j'ai ca comme erreur:
variable 'eepromcfg1' has initializer but incomplete type

 
Je te conseille plutôt de remettre la protection et de chercher à corriger les problèmes qui en découlent.
 

Ben oui mais avec des protections j'ai l'impression que le header n'est absolument pas pris en compte, alors que j'ai bien ces includes dans l'eeprom_testsuite.c

Je désespère

C'est complètement barge ce truc.

Si je mets le #include "eeprom_i2c.h", il rale parce qu'il n'a pas de référence à ces fonctions (alors qu'elles y sont).
Si j'enlève cet #include "eeprom_i2c.h", il rale parce qu'il ne connait pas ces noms de fonctions.

Donc c'est qu'il doit bien remarquer la présence de ce header, pourquoi ne trouve-t-il pas les prototypes de fonctions qui y sont définis???

 
 
S'il est pas pris en compte c'est qu'il a déjà été inclus (directement ou indirectement), c'est justement le but de la protection contre les inclusions multiples.
 
Ton problème de undefined reference c'est plutôt un problème d'édition de liens (lib qui manque ou .o qui manque).

Mais les fichiers .o sont bien là
 

 
 

Ils sont bien linkés (vérifie dans ton makefile) ?

Ben dans le makefile de la lib il y a ca:

 
Dans le makefile principal qui fait appel au makefile de la lib j'ai rajouté les 2 variables.
 
$(EEPROMSRC)

 
$(EEPROMINC) pour les headers:

 
Quand je vois le reste j'ai l'impression que c'est comme ca qu'il faut faire