Créer une librairie langage C

**SamPirate62** · 07/12/2018, 10h28

Bonjour à tous,

J'aimerais savoir s'il est possible de créer une librairie en langage C donc le code ne serait pas visible ?
Le but est de fournir a des clients des algorithmes implémentables dans leur programme sans qu'ils puissent voir le code source.

Merci,

**Bktero** · 07/12/2018, 11h05

Oui. A ceci prêt que l'assembleur sera toujours visible.

Mais je vois que tu es "Ingénieur développement matériel électronique" donc je vais quand même te poser la question "quelle est ta ou tes plateformes cibles ?".

De manière générale, à qui souhaites-tu distribuer cette bibliothèque ?

**SamPirate62** · 07/12/2018, 12h32

C'est pour de la clientèle de l'entreprise où je travaille ,c'est pour une application sur microcontrôleur mais le code sera fait de manière indépendant du micro utilisé.

Quand tu dis que l'assembleur sera toujours visible, c'est que au moment de la compilation, le compilateur va forcément transformer la librairie en assembleur (lié à la cible sur laquelle est implémenté le code ?)

Aussi, implicitement, mon poste voulait aussi dire, comment fait-on ce genre de chose ?

**foetus** · 07/12/2018, 14h06

Envoyé par SamPirate62

le compilateur va forcément transformer la librairie en assembleur

Techniquement non

C'est le linker qui produit de l'assembleur.

Le compilateur lui sort du pseudo-assembleur, mais contrairement au Java par exemple, ce pseudo-assembleur n'est pas normé [et apparemment, même en C++ personne ne veut le normer]

**Médinoc** · 07/12/2018, 15h04

Techniquement de nos jours ni l'un ni l'autre ne produit de l'assembleur, car ça fait belle lurette que le back-end du compilateur passe directement de "arbre syntaxique" à "code objet" (code machine séparé en mini-sections qui attendent l'édition de liens, extension .obj sous Visual et .o sous GCC).
(Edit: Du moins, quand la Link-Time Code Generation n'est pas activée)

Mais quand on passe l'option appropriée, c'est bel et bien le compilateur qui sort un fichier "source assembleur" (généralement .asm sous Visual, .s sous GCC) qui peut ensuite lui être passé directement pour qu'il en fasse un "code objet"...

**Bktero** · 07/12/2018, 16h51

Envoyé par SamPirate62

C'est pour de la clientèle de l'entreprise où je travaille ,c'est pour une application sur microcontrôleur mais le code sera fait de manière indépendant du micro utilisé.

Et là tu vas rentrer dans l'enfer de la livraison sous forme de binaires...

J'ai travaillé pour une entreprise qui vendait des bibliothèques sous forme de binaires, et dans ma vie j'ai travaillé avec des bibliothèques en binaires et en sources en tant qu'utilisateurs. Il faut avoir de très bonnes raisons de ne pas le faire en sources.

Pourquoi ?

Parce que pour fournir ta bibliothèque en binaire, il faut compiler ton code. Donc il te faut plusieurs compilateurs, potentiellement avec des licences que ton entreprise devra payer.. Si tu vises par exemple du ARM Cortex-M3, du ARM Cortex-M4 et du Renesas RX113, il te faut 3 compilateurs a priori. Mais pour ARM Cortex-M, tu as du GCC, du IAR, du Keil. Et je crois que pour Renesas RX113 il y a 2 toolchains (une gratuite, une payante). En tout, ça fait donc 8 compilateurs. Tu devras potentiellement gérer des variantes, par exemple une version avec et une version sans log. Tu devras peut-être gérer des options pour une même cible, par exemple sur Cortex-M4 avec utilisation de la FPU ou sans utilisation de la FPU ou avec l'ABI mixte. J'ai déjà perdu le compte du nombre de variantes...

Au final, tu te retrouves avec énormément de binaires à produire, maintenir, tester, supporter.

Autre gros soucis du binaire, ce n'est pas débogable côté client, qui risque de t'appeler pour te dire "ça marche pas" à tout bout de champ.

Si tu es prêt accepter tout ça, tu peux livrer un ensemble de *.o et de *.h. En étant un peu plus propre, tu feras archive *.a (ou *.lib ou *.truc selon le compilateur) pour regrouper les *.o. Comment faire ? Ca dépend de ta cible et donc de la toolchain qui va avec. Voici par exemple pour du GCC : https://gradot.wordpress.com/2013/11...statique-en-c/

Comment voir le code assembleur ? Simplement en dé-assemblant ta bibliothèque. Avec GCC, tu as la commande objdump -d pour faire ça.

**SamPirate62** · 10/12/2018, 14h55

Merci pour toutes ces informations.

J'ai testé un *.o + *.h et *.a avec Codeblocks ça fonctionne. Je vais essayer de compiler avec notre compilateur et de tester ce bout de code avec notre plateforme actuelle.

On va y réfléchir parce qu’effectivement ça peut vite devenir lourd à gérer.

Merci beaucoup,

**SamPirate62** · 10/12/2018, 16h03

Juste une dernière aide avant de clore.

J'ai compilé sous CodeBlocks et GNU Tools ARM Embedded (compilateur de notre plateform de dév). Pas d'erreur de compilation.
J'ai essayé d'appeler la fonction de la librairie que j'ai générée mais ça ne fonctionne pas.

J'ai généré un *.a à partir d'un projet comportant un *.c et un *.h. Le point h comporte le prototype de la fonction codée dans le *.c.
Je link bien la libraire dans mon logiciel (Kinetis Design Studio pour info) et j'ajoute le *.a et le *.h dans mon projet, j''appelle le *.h dans mon main et j’appelle la fonction mais le compilateur me revnoie "undefined reference to 'mafonction'....

Je dois mal faire les choses mais je ne vois pas où..

**Kannagi** · 10/12/2018, 16h09

Envoyé par SamPirate62

J'ai compilé sous CodeBlocks

Techniquement Code::Block ne compile rien , c'est juste un IDE et éventuellement tu peux lui assigner un compilateur (par défaut il utilise gcc sur Linux ou MinGW sur Windows).
Tu peux lui rajouter autant de compilateur que tu veux (tu as sur C::B un build target qui permet de changer de cible).

**SamPirate62** · 10/12/2018, 16h20

Désole si ma phrase précédente n'est pas claire : J'ai assigné GNU Tools ARM Embedded à CodeBlocks et j'ai compilé.

**Bktero** · 10/12/2018, 17h04

Je te renvoie vers cette entrée de la FAQ : https://c.developpez.com/faq/?page=G...mbol-not-found

Tu peux faire un arm-none-eabi-objdump -t ta_lib.a pour avoir la liste de ce qu'elle contient.

Mais pourquoi faire une partie du travail dans C::B et une autre dans Kinetis ?

**SamPirate62** · 11/12/2018, 11h57

A priori il n'y a rien dans ma librairie, .text, .data et.bss sont à 0.

J'ai pourtant créer une fonction simple dans un fichier *.c avec son prototype. Puis j'ai déclaré le même prototype en extern dans son .h. Je passe à côté de quelque chose ?

Sinon pour répondre à la question précédente :
Je fais un test de principe de fonctionnement, j'utilise CodeBlocks pour générer ma librairie avec le compilateur voulue (en l’occurrence GNU Tools ARM Embedded) puis j'importe la librairie dans Kinetis Design Studio qui est le logicielle de développement de notre microcontrôleur qui utilise GNU Tools ARM Embedded pour voir si ça fonctionne bien.
Si ça au moins ça ça fonctionne, je pourrais tout générer via CodeBlocks et le compilateur souhaité.
Mais bon pour l'instant ce n'est pas le cas.

**Bktero** · 11/12/2018, 12h07

Sans information supplémentaire (ligne de commande pour compiler, log du build, résultat de objdump -t), difficile de t'aider.

**SamPirate62** · 11/12/2018, 12h14

Sorry. J'ai ajouté un screenshot du objdump et un screenshot de la toolchain utilisée. La fonction c'est AddTen, elle à l'air d'être là.

A priori ça fonctionne sous GNU GCC mais pas sous la version ARM Embedded.

**SamPirate62** · 11/12/2018, 12h46

Sur la page de download il n'y a pas de version win64, du coup j'ai installé une win32, c'est possible que ça vienne de là ?

**Bktero** · 11/12/2018, 13h59

On peut voir le log complet pour builder ce .a avec C::B ?

On peut voir log log complet de Kinetis menant à l'erreur ?

Non, je ne pense que que ça vienne pas des 32 ou 64 bits de ta toolchain.

T'as essayé avec juste le *.o et pas avec le *.a ?

**SamPirate62** · 11/12/2018, 15h44

Il y avait effectivement une information dans le log de C::B : "......plugin needed to handle lto object"
Après avoir fouillé un peu j'ai changé l'exe de la library static avec arm-none-eabi-gcc-ar.exe (et non arm-none-eabi-ar.exe). Le problème a disparu, j'ai pu utilisé la library *.a compilée dans un projet C::B sans problème.

Par contre j'ai essayé de l'intégrer dans ma plateform microcontrôleur KDS mais j'ai toujours le même soucis.

Dans le log de KDS j'obtiens :

Building target: Battery Discharge measurement.elf
Invoking: Cross ARM GNU C++ Linker
arm-none-eabi-g++ -mcpu=cortex-m0plus -mthumb -O0 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -Wall -g3 -T "C:/Users/...../Desktop/Mesure decharge batterie/Battery Discharge measurement/Project_Settings/Linker_Files/ProcessorExpert.ld" -Xlinker --gc-sections -L"C:/Users/...../Desktop/Mesure decharge batterie/Battery Discharge measurement/Sources" -Wl,-Map,"Battery Discharge measurement.map" -specs=nosys.specs -specs=nano.specs -Xlinker -z -Xlinker muldefs -o "Battery Discharge measurement.elf" ./Static_Code/System/PE_low_level_init.o ./Sources/Battery.o ./Sources/Events.o ./Sources/main.o ./SDK/platform/utilities/src/fsl_debug_console.o ./SDK/platform/utilities/src/fsl_misc_utilities.o ./SDK/platform/utilities/src/print_scan.o ./SDK/platform/system/src/interrupt/fsl_interrupt_manager.o ./SDK/platform/system/src/clock/MKL43Z4/fsl_clock_MKL43Z4.o ./SDK/platform/system/src/clock/fsl_clock_manager.o ./SDK/platform/system/src/clock/fsl_clock_manager_common.o ./SDK/platform/osa/src/fsl_os_abstraction_bm.o ./SDK/platform/hal/src/uart/fsl_uart_hal.o ./SDK/platform/hal/src/tpm/fsl_tpm_hal.o ./SDK/platform/hal/src/sim/MKL43Z4/fsl_sim_hal_MKL43Z4.o ./SDK/platform/hal/src/rtc/fsl_rtc_hal.o ./SDK/platform/hal/src/port/fsl_port_hal.o ./SDK/platform/hal/src/osc/fsl_osc_hal.o ./SDK/platform/hal/src/mcglite/fsl_mcglite_hal.o ./SDK/platform/hal/src/mcglite/fsl_mcglite_hal_modes.o ./SDK/platform/hal/src/lpuart/fsl_lpuart_hal.o ./SDK/platform/hal/src/adc16/fsl_adc16_hal.o ./SDK/platform/drivers/src/tpm/fsl_tpm_common.o ./SDK/platform/drivers/src/tpm/fsl_tpm_driver.o ./SDK/platform/drivers/src/rtc/fsl_rtc_common.o ./SDK/platform/drivers/src/adc16/fsl_adc16_common.o ./SDK/platform/drivers/src/adc16/fsl_adc16_driver.o ./SDK/platform/devices/MKL43Z4/startup/gcc/startup_MKL43Z4.o ./SDK/platform/devices/MKL43Z4/startup/system_MKL43Z4.o ./SDK/platform/devices/startup.o ./Generated_Code/Cpu.o ./Generated_Code/adConv1.o ./Generated_Code/clockMan1.o ./Generated_Code/hardware_init.o ./Generated_Code/osa1.o ./Generated_Code/pin_init.o ./Generated_Code/tpmTmr3.o -lGSR
./Sources/main.o: In function `main':
C:\Users\.....\Desktop\Mesure decharge batterie\Battery Discharge measurement\Debug/../Sources/main.c:114: undefined reference to `AddTen'
collect2.exe: error: ld returned 1 exit status
makefile:76: recipe for target 'Battery Discharge measurement.elf' failed
make: *** [Battery Discharge measurement.elf] Error 1

Dans le log C::B j'obtiens:

arm-none-eabi-gcc.exe -Wall -std=c99 -mcpu=cortex-m0plus -mthumb -O0 -fsigned-char -g3 -O2 -Wall -ffreestanding -flto -c "C:\Users\....\Desktop\Bibliotheque langage C\Biblio 2\GSR.c" -o obj\Release\GSR.o
cmd /c if exist bin\Release\libGSR.a del bin\Release\libGSR.a
arm-none-eabi-gcc-ar.exe -r -s bin\Release\libGSR.a obj\Release\GSR.o
c:\program files (x86)\gnu tools arm embedded\7 2018-q2-update\bin\../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/bin/ar.exe: creating bin\Release\libGSR.a
Output file is bin\Release\libGSR.a with size 2.91 KB

**Bktero** · 11/12/2018, 17h38

Tu as -lGSR mais le fichier .a est-il bien disponible dans les chemins de recherche ? Si tu mets -lTOTO ça crashe ? Si non, il faut que tu mettes ton *.a au bon endroit ou tu ajoutes le chemin avec -L

Tu n'es pas en train de mixer du C et du C++ à tout hasard ?

**SamPirate62** · 13/12/2018, 09h37

A priori bien dispo dans les chemins de recherche (voir PJ). Il faut bien retiré le "lib" et le ".a" (libGSR.a -->GSR) pour inclure la librairie.

Non je ne mixe pas de C et C++, juste du C (après il y a de la génération automatique de code, peut-être qu'il y en a mais je ne pense pas), j'ai aussi vu que le linker était C++ dans KDS...c'est la config par défaut sur ce logiciel, ça ne m'a jamais posé de soucis.

Si j'inclus lTOTO, l'erreur est "cannot find -lTOTO". Donc a priori libGSR.a est bien vu.

**Bktero** · 13/12/2018, 10h03

Envoyé par SamPirate62

Non je ne mixe pas de C et C++, juste du C (après il y a de la génération automatique de code, peut-être qu'il y en a mais je ne pense pas), j'ai aussi vu que le linker était C++ dans KDS...c'est la config par défaut sur ce logiciel, ça ne m'a jamais posé de soucis.

Tant que tu es dans Kinetis, ça ne pose pas de soucis car il fait tout lui même comme un grand. En revanche, le code que tu apportes de l'extérieur n'est peut-être pas tout à fait comme attendu.

Il est possible que tu aies un problème avec le name mangling. Ce lien devrait te permettre de comprendre le potentiel problème : https://www.geeksforgeeks.org/extern-c-in-c/ Essaye de modifier le header de la bibliothèque pour rajouter des extern "C" conditionellement au langage :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
#ifdef __cplusplus  
extern "C" { 
#endif 
    // déclarations de tes fonctions ici
#ifdef __cplusplus 
} 
#endif

Créer une librairie langage C

C

Partager

Partager