undefined reference to _kill, _getpid and _sbrk

[sebastien-begue]

Bonjour à tous !

Je suis ici car je n'arrive pas à resoudre mon problème : en faite je suis en train de créer un projet C sur eclipse CDT C/C++ IDE, avec le compilateur arm-none-eabi-gcc ( c'est pour une carte embarquée STM32 ), et j'ai implémenté polarSSL pour avoir un serveur embarqué qui gère le https.

Donc j'ai biensûr regardé les forums à propos de ces erreurs, et ils expliquent qu'il faut supprimer les "printf", "malloc", "file", "path" car en effet je suis sur un embarqué et ça ne gère pas ça ( d'autant plus que sur eclipse j'ai pas de terminal ) ; MAIS après avoir effectué/supprimé tout tout ça, j'ai encore et toujours ces erreurs... pensez-vous pouvoir m'aider afin de résoudre mon problème s'il vous plait ?

Merci d'avance pour vos réponses.

(je vous mets aussi ci-dessus un impr écran de mes erreurs ).




Cordialement,
Sébastien.
-----

[gienas]

Bonjour sebastien-begue et tout le groupe

... problème ... projet C sur eclipse CDT C/C++ IDE, avec le compilateur ...

Bien sûr, c'est du logiciel, mais il me semble que les spécialistes habitués à ton problème seront plus nombreux sur le forum d'électronique.

Je vais l'y déplacer. Si je me trompe, il sera toujours temps de changer.

Ta liste d'erreurs est difficile à lire. Pourtant, elle peut donner des indices précieux. S'agissant de texte pur, il serait préférable de la redonner en ASCII, avec la balise code

Liste des erreurs ...

[sebastien-begue]

Re-bonjour !

Merci d'abord pour ce geste gienas !

Alors voilà les erreurs que j'ai avec une meilleure clarté :

c:/program files/aim/uone/tools/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/armv7-m/libc.a(lib_a-signalr.o): In function '_kill_r' : signalr.c:(.text._kill_r+0xe): undefined reference to '_kill'
c:/program files/aim/uone/tools/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/armv7-m/libc.a(lib_a-signalr.o): In function '_getpid_r' : signalr.c:(.text._kill_r+0xe): undefined reference to '_getpid'
c:/program files/aim/uone/tools/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/armv7-m/libc.a(lib_a-signalr.o): In function '_sbrk_r' : signalr.c:(.text._kill_r+0xe): undefined reference to '_sbrk'

Des idées alors s'il vous plait ?


Cordialement,
Sébastien.

[Yoruk]

Manque une librairie ?

[A voir en vidéo sur Futura]

[sebastien-begue]

Ben justement je ne veux pas utiliser la librairie associées aux fonctions _kill, _getpid et _sbrk, qui a ce que j'ai vu sur internet étaient des fonctions qui étaient appelés en interne par l'utilisation de fonctions comme printf(), malloc(), etc... OR je les ai tous enlevés de mes codes source !! donc je suis en quête d'une autre explication... car là je ne vois pas qu'est ce qui appelle ces fonctions...

Merci de ta réponse.


Cordialement,
Sébastien.

[Yoruk]

Il reste sans doute une fonction dans ton code qui les appelle...

Pourquoi tu ne veux pas inclure les librairies concernées ?

[spown]

Bonjour/bonsoir est Bienvenue sur FUTURA,

Ton problème, c'est ton Linker ne trouves pas les librairies.

Je vois que tu utilises la version 4.6 du ARM GNU GCC , mieux de passer sur la dernière version(4.8) ==> https://launchpad.net/gcc-arm-embedded/+download ( dépend de ton OS )

prend ce fichier associé le : http://myavr.chkronline.de/html_stm3...pse_tut10.html

[ftorama]

J'ai l'impression que tu t'embrouilles entre librairies, fonctions standards du C, fonctions du C++ et fonctions d'un OS multi-tâches...

Kill et getpid, c'est lié à la gestion de process dans un OS multitâches, printf, c'est simplement écrire sur un flux de sortie et c'est pleinement géré par du C....

File et path, ça va être lié à un système de gestion de fichiers.

Rien ne t'empêche d'avoir toutes ces fonctions sur un STM32 et même de le programmer en C++ mais encore faut-il utiliser les bonnes librairies et les bons middlewares. Une appli PC ne se porte pas si simplement sur un micro, mais beaucoup de choses sont possibles avec ces micros.

[sebastien-begue]

Merci d'abord pour vos réponses !

spown, je ne peux pas utiliser syscalls.c car je suis sur windows 7 ... désolé j'ai oublié de préciser mon OS, chose essentielle !

...Et les kill et getpid sont dediés aux librairies linux, donc je ne peux pas les rajouter, non ??


Cordialement,
Sébastien.

[spown]

Tiens, suis les étapes dans ce lien ==> http://www.acmesystems.it/foxg20_eclipse_windows_c ( tu dois remplacer ton GCC par celui là https://sourcery.mentor.com/sgpp/lit...al/release2029 )

[spown]

Voir ce lien (debbuging) : http://stm32discovery.nano-age.co.uk...d-code-sourcey

ca aussi (setting) : http://stm32discovery.nano-age.co.uk...ry-development
ca aussi (NewLib) : http://stm32discovery.nano-age.co.uk...cery-lite-eabi

[freepicbasic]

Ton compilateur te dis que tu fais appel a des ou une fonction dans "signal.o" qui fait appel à des fonctions qui sont dans d'autres librairies

Si tu veux continuer avec ta méthode , c est a dire sans linker ces fameuses librairies , et conserver ces fonctions,
Il faudra extraire les .O demandés de ces librairies "exclus" et linker tout les .O avec ton prog
avec un prog du genre lib (Microsoft) tlib (Borland) ou glib (GNU) selon le compilateur.

En espérant que ces .O n'ont pas d'autres liens eux aussi...
si non même opération , voir si c est rentable dans ce cas.

D'ailleurs il est possible que la fonction dans signal.o ne soit même pas utilisée, ce qui serait un comble. LOL
Dans ce cas il faudrait la supprimer de la lib

[ftorama]

...Et les kill et getpid sont dediés aux librairies linux, donc je ne peux pas les rajouter, non ??

Tous les autres OS seront contents de l'apprendre. Bref ce sont des fonctions standards d'un système multitâche et tu retrouveras ces fonctions ou leur équivalent dans des OS portales sur le STM32 comme FreeRTOS, UCLinux.

Porter un soft pour Linux sur un micro me paraît légèrement scabreux d'autant que les solutions SSL sur STM32 ne manquent pas. Il suffit de chercher dans cette doc pour s'en convaincre:
http://www.st.com/st-web-ui/static/a..._solutions.pdf

[sebastien-begue]

Bonsoir !

Merci d'abord pour tous ces conseils !

Je regarderai le .o demain matin et je reviendrai ici par la suite si un problème persiste toujours ! car en effet, j'aimerai ne pas avoir à passer par un changement d'outil de debug... ( aussi je trouve bizarre qu'il y a un appel système à _sbrk car j'ai supprimé tous les malloc() et simplement mis des memset(), et surtout vérifié plusieurs fois ... )

...En tout cas s'il faudra que je passe par là, j'aimerai savoir si ces outils de debogage rajoute des fichiers genre va me prendre de la flash côté micro ou tout reste côté PC ? car en effet je pense que ça va être risqué à ce niveau là... non ?

Cordialement,
Sébastien.