Discussion :

[gronaze]

Bonsoir,

Je viens de lire des doc sur les bibliothèques en C, mais je ne suis pas sûr d'avoir bien compris.

Effectivement, je travaille sur un projet avec un OS temps réel maison, avec chaque tâche compilée séparément.
Chaque tâche fait appel à une même bibliothèque statique, et chaque tâche est compilée avec sa bibliothèque.
Ce qui fait que pour mes 10 tâches, à chaque fois j'embarque 10 fois la bibliothèque.

Je me demandais, si il serait possible pour libérer de la place RAM/ROM, de faire une bibliothèque/library dynamique ?
Si je résume bien je devrais avoir le mapping ROM suivant, (je ne traite pas le mapping RAM qui serait dans le même genre).
ROM:
0x0000-0x0FFF tâche 1
0x1000-0x1FFF tâche 2
...
0x9000-0x9FFF tâche 10
0xA000-0xAFFF bibliothèque

Est-ce correct ?

Merci pour votre aide,

Bat

[foetus]

Il y a même 3

Statique: .lib ou .a. En gros c'est du binaire qui va être injecté dans ton exécutable lors du linkage

Dynamique: .dll ou .so. C'est un fichier externe qui sera mappé en mémoire en partie (juste le code qui est nécessaire). Donc c'est chiant parce qu'il y a un processus d'ouverture (LoadLibrary) et de fermeture

Tu as un mode entre les deux (sous Linux je ne sais pas ): tu vas avoir une bibliothèque statique .lib dont les fonctions/ procédures/ méthodes vont pointer vers une DLL. Donc le processus ouverture/ fermeture est automatique avec les avantages de la DLL (exécutable plus petit et chargement seulement du code nécessaire)
Mais tu auras toujours à trimballer et à gérer la/ les DLL(s)


Édit: Merci Obsidian , mais je confonds toujours
D'ailleurs lorsque je codais pour iPhone, on devait compiler en plusieurs versions les bibliothèques (en changeant la plateforme: x86, ARMV6, ARMV7 et ARMV7s) et utiliser les outils comme ar pour faire une grosse bibliothèque à mettre dans son projet

[Obsidian]

Il y a même 3

Statique: .lib ou .so. En gros c'est du binaire qui va être injecté dans ton exécutable lors du linkage

Dynmaique: .dll ou .a. C'est un fichier externe qui sera mappé en mémoire en partie (juste le code qui est nécessaire). Donc c'est chiant parce qu'il y a un processus d'ouverture (LoadLibrary) et de fermeture

C'est l'inverse : sous UNIX, ce sont les « *.so » qui sont les bibliothèques dynamiques (« Shared Object ») et les « *.a » qui forment les bibliothèques statiques. Les fichiers « *.a » sont en fait eux-mêmes des archives, produites avec l'archiveur historique ar, qui a notamment été dérivé en tar (Tape Archiver) par la suite. Donc ici, un outil qui se contente de rassembler plusieurs fichiers en un seul, bout à bout et sans même les comprimer.

Donc un « *.a » n'est même pas forcément, en soi, une bibliothèque statique. Mais quand c'est le cas, le fichier « *.a » sert en fait uniquement à rassembler tous les fichiers objets « *.o » produits par le compilateur. Y faire référence permet de les utiliser exactement comme si c'était notre compilateur lui-même qui venait de compiler différentes unités « *.c » vers leur fichier objet « *.o ».

[dalfab]

Bonjour,

Effectivement, je travaille sur un projet avec un OS temps réel maison, avec chaque tâche compilée séparément.
Chaque tâche fait appel à une même bibliothèque statique, et chaque tâche est compilée avec sa bibliothèque.

Si tu utilises un OS maison, c'est l'OS qui doit gérer les shared area, il faut voir avec sa documentation.
Par exemple, pour un module dynamique utilisé par 3 taches, tu auras de 1 à 4 segments pour gérer la RAM du module et un seul segment partagé pour sa ROM.