Bonjour,
Je souhaite cr=E9er une API (sous AIX) fournissant 2 fonctions :int
f1(arg1); et int f2(arg1);
Ces deux fonctions sont =E9crit dans un fichier api.c (et api.h).
Le probl=E8me c'est que c'est deux fonctions sont assez cons=E9quentes,
et donc font appel =E0 d'autres sous fonctions d=E9fini dans source.c (et
le fichier d'entete source.h).
Le probl=E8me c'est que si je cr=E9e une librairie de la mani=E8re
suivante :
ar r api api.o source.o
et
ranlib api
Lorsque je livrerai la librairie libapi on pourra utiliser les
fonctions f1, f2 mais aussi mes sous fonctions. Au d=E9part j'avais tout
mis dans le m=EAme fichier et mis les sous fonctions comme "static",
mais le fichier devient trop grand.
Comment puis-je faire pour que seul les fonctions souhait=E9es soit
r=E9utilisables ? Au d=E9part je pensais fournir que le api.h, comme =E7a
les utilisateurs ne connaissant pas les autres, =E0 priori ils ne les
utiliseront pas. Mais se n'est pas tr=E8s rigoureux.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Eric Levenez
Le 4/01/07 19:05, dans , « xdunat » a écrit :
Cette question n'a rien à voir avec le C, mais est uniquement liée à ta chaîne de compilation. Il faudrait poster ta question sur un NG lié à ton système.
Lorsque je livrerai la librairie libapi on pourra utiliser les fonctions f1, f2 mais aussi mes sous fonctions. Au départ j'avais tout mis dans le même fichier et mis les sous fonctions comme "static", mais le fichier devient trop grand.
Tu mets toutes tes fonctions annexes dans des sources séparés et tu les places dans une bibliothèque. Ensuite tu prends ton source avec tes 2 fonctions et tu fais une édition de lien partiel avec ta bibliothèque. Il ne restera en extern que tes fonctions. Regarde la doc de ton linker.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 4/01/07 19:05, dans
<1167933934.752302.70950@s80g2000cwa.googlegroups.com>, « xdunat »
<xavier.dunat@worldonline.fr> a écrit :
Cette question n'a rien à voir avec le C, mais est uniquement liée à ta
chaîne de compilation. Il faudrait poster ta question sur un NG lié à ton
système.
Lorsque je livrerai la librairie libapi on pourra utiliser les
fonctions f1, f2 mais aussi mes sous fonctions. Au départ j'avais tout
mis dans le même fichier et mis les sous fonctions comme "static",
mais le fichier devient trop grand.
Tu mets toutes tes fonctions annexes dans des sources séparés et tu les
places dans une bibliothèque. Ensuite tu prends ton source avec tes 2
fonctions et tu fais une édition de lien partiel avec ta bibliothèque. Il ne
restera en extern que tes fonctions. Regarde la doc de ton linker.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Cette question n'a rien à voir avec le C, mais est uniquement liée à ta chaîne de compilation. Il faudrait poster ta question sur un NG lié à ton système.
Lorsque je livrerai la librairie libapi on pourra utiliser les fonctions f1, f2 mais aussi mes sous fonctions. Au départ j'avais tout mis dans le même fichier et mis les sous fonctions comme "static", mais le fichier devient trop grand.
Tu mets toutes tes fonctions annexes dans des sources séparés et tu les places dans une bibliothèque. Ensuite tu prends ton source avec tes 2 fonctions et tu fais une édition de lien partiel avec ta bibliothèque. Il ne restera en extern que tes fonctions. Regarde la doc de ton linker.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
xdunat
Le 4/01/07 19:05, dans , « xdunat »
Lorsque je livrerai la librairie libapi on pourra utiliser les fonctions f1, f2 mais aussi mes sous fonctions. Au départ j'avais tout mis dans le même fichier et mis les sous fonctions comme "static", mais le fichier devient trop grand.
Tu mets toutes tes fonctions annexes dans des sources séparés et tu l es places dans une bibliothèque. Ensuite tu prends ton source avec tes 2 fonctions et tu fais une édition de lien partiel avec ta bibliothèque . Il ne restera en extern que tes fonctions. Regarde la doc de ton linker.
OK. Merci. Après quelques recherches sur mon éditeur de lien (ld),
j'ai fini par trouver comment le faire.
Le 4/01/07 19:05, dans
<1167933934.752302.70950@s80g2000cwa.googlegroups.com>, « xdunat »
Lorsque je livrerai la librairie libapi on pourra utiliser les
fonctions f1, f2 mais aussi mes sous fonctions. Au départ j'avais tout
mis dans le même fichier et mis les sous fonctions comme "static",
mais le fichier devient trop grand.
Tu mets toutes tes fonctions annexes dans des sources séparés et tu l es
places dans une bibliothèque. Ensuite tu prends ton source avec tes 2
fonctions et tu fais une édition de lien partiel avec ta bibliothèque . Il ne
restera en extern que tes fonctions. Regarde la doc de ton linker.
OK. Merci. Après quelques recherches sur mon éditeur de lien (ld),
Lorsque je livrerai la librairie libapi on pourra utiliser les fonctions f1, f2 mais aussi mes sous fonctions. Au départ j'avais tout mis dans le même fichier et mis les sous fonctions comme "static", mais le fichier devient trop grand.
Tu mets toutes tes fonctions annexes dans des sources séparés et tu l es places dans une bibliothèque. Ensuite tu prends ton source avec tes 2 fonctions et tu fais une édition de lien partiel avec ta bibliothèque . Il ne restera en extern que tes fonctions. Regarde la doc de ton linker.
OK. Merci. Après quelques recherches sur mon éditeur de lien (ld),
j'ai fini par trouver comment le faire.
xdunat
Le 4/01/07 19:05, dans , « xdunat »
Lorsque je livrerai la librairie libapi on pourra utiliser les fonctions f1, f2 mais aussi mes sous fonctions. Au départ j'avais t out mis dans le même fichier et mis les sous fonctions comme "static", mais le fichier devient trop grand.
Tu mets toutes tes fonctions annexes dans des sources séparés et tu les places dans une bibliothèque. Ensuite tu prends ton source avec tes 2 fonctions et tu fais une édition de lien partiel avec ta bibliothèq ue. Il ne restera en extern que tes fonctions. Regarde la doc de ton linker.
OK. Merci. Après quelques recherches sur mon éditeur de lien (ld),
j'ai fini par trouver comment le faire.
Ben en fait, ce n'est pas ça. Toutes mes fonctions sont visibles.
Si le forum n'est pas le bon pour ma question, ou dois-je poster ?
Le 4/01/07 19:05, dans
<1167933934.752302.70950@s80g2000cwa.googlegroups.com>, « xdunat »
Lorsque je livrerai la librairie libapi on pourra utiliser les
fonctions f1, f2 mais aussi mes sous fonctions. Au départ j'avais t out
mis dans le même fichier et mis les sous fonctions comme "static",
mais le fichier devient trop grand.
Tu mets toutes tes fonctions annexes dans des sources séparés et tu les
places dans une bibliothèque. Ensuite tu prends ton source avec tes 2
fonctions et tu fais une édition de lien partiel avec ta bibliothèq ue. Il ne
restera en extern que tes fonctions. Regarde la doc de ton linker.
OK. Merci. Après quelques recherches sur mon éditeur de lien (ld),
j'ai fini par trouver comment le faire.
Ben en fait, ce n'est pas ça. Toutes mes fonctions sont visibles.
Si le forum n'est pas le bon pour ma question, ou dois-je poster ?
Lorsque je livrerai la librairie libapi on pourra utiliser les fonctions f1, f2 mais aussi mes sous fonctions. Au départ j'avais t out mis dans le même fichier et mis les sous fonctions comme "static", mais le fichier devient trop grand.
Tu mets toutes tes fonctions annexes dans des sources séparés et tu les places dans une bibliothèque. Ensuite tu prends ton source avec tes 2 fonctions et tu fais une édition de lien partiel avec ta bibliothèq ue. Il ne restera en extern que tes fonctions. Regarde la doc de ton linker.
OK. Merci. Après quelques recherches sur mon éditeur de lien (ld),
j'ai fini par trouver comment le faire.
Ben en fait, ce n'est pas ça. Toutes mes fonctions sont visibles.
Si le forum n'est pas le bon pour ma question, ou dois-je poster ?
jacob navia
Le 4/01/07 19:05, dans , « xdunat »
Lorsque je livrerai la librairie libapi on pourra utiliser les fonctions f1, f2 mais aussi mes sous fonctions. Au départ j'avais tout mis dans le même fichier et mis les sous fonctions comme "static", mais le fichier devient trop grand.
Tu mets toutes tes fonctions annexes dans des sources séparés et tu les places dans une bibliothèque. Ensuite tu prends ton source avec tes 2 fonctions et tu fais une édition de lien partiel avec ta bibliothèque. Il ne restera en extern que tes fonctions. Regarde la doc de ton linker.
OK. Merci. Après quelques recherches sur mon éditeur de lien (ld), j'ai fini par trouver comment le faire.
Ben en fait, ce n'est pas ça. Toutes mes fonctions sont visibles.
Si le forum n'est pas le bon pour ma question, ou dois-je poster ?
C'est impossible mon vieux, au moins mon linker ne fais pas ca, et je vois pas comment ca pourrait marcher.
Si les sous-fonctions sont invisibles, comment les trouver alors pour fair l'edition de liens?
jacob
http://www.cs.virginia.edu/~lcc-win32
Le 4/01/07 19:05, dans
<1167933934.752302.70950@s80g2000cwa.googlegroups.com>, « xdunat »
Lorsque je livrerai la librairie libapi on pourra utiliser les
fonctions f1, f2 mais aussi mes sous fonctions. Au départ j'avais tout
mis dans le même fichier et mis les sous fonctions comme "static",
mais le fichier devient trop grand.
Tu mets toutes tes fonctions annexes dans des sources séparés et tu les
places dans une bibliothèque. Ensuite tu prends ton source avec tes 2
fonctions et tu fais une édition de lien partiel avec ta bibliothèque. Il ne
restera en extern que tes fonctions. Regarde la doc de ton linker.
OK. Merci. Après quelques recherches sur mon éditeur de lien (ld),
j'ai fini par trouver comment le faire.
Ben en fait, ce n'est pas ça. Toutes mes fonctions sont visibles.
Si le forum n'est pas le bon pour ma question, ou dois-je poster ?
C'est impossible mon vieux, au moins mon linker ne fais pas ca,
et je vois pas comment ca pourrait marcher.
Si les sous-fonctions sont invisibles, comment les trouver alors
pour fair l'edition de liens?
Lorsque je livrerai la librairie libapi on pourra utiliser les fonctions f1, f2 mais aussi mes sous fonctions. Au départ j'avais tout mis dans le même fichier et mis les sous fonctions comme "static", mais le fichier devient trop grand.
Tu mets toutes tes fonctions annexes dans des sources séparés et tu les places dans une bibliothèque. Ensuite tu prends ton source avec tes 2 fonctions et tu fais une édition de lien partiel avec ta bibliothèque. Il ne restera en extern que tes fonctions. Regarde la doc de ton linker.
OK. Merci. Après quelques recherches sur mon éditeur de lien (ld), j'ai fini par trouver comment le faire.
Ben en fait, ce n'est pas ça. Toutes mes fonctions sont visibles.
Si le forum n'est pas le bon pour ma question, ou dois-je poster ?
C'est impossible mon vieux, au moins mon linker ne fais pas ca, et je vois pas comment ca pourrait marcher.
Si les sous-fonctions sont invisibles, comment les trouver alors pour fair l'edition de liens?
jacob
http://www.cs.virginia.edu/~lcc-win32
xdunat
Le 4/01/07 19:05, dans , « xdunat »
Lorsque je livrerai la librairie libapi on pourra utiliser les fonctions f1, f2 mais aussi mes sous fonctions. Au départ j'avais t out mis dans le même fichier et mis les sous fonctions comme "static", mais le fichier devient trop grand.
Tu mets toutes tes fonctions annexes dans des sources séparés et tu les places dans une bibliothèque. Ensuite tu prends ton source avec tes 2 fonctions et tu fais une édition de lien partiel avec ta bibliothèq ue. Il ne restera en extern que tes fonctions. Regarde la doc de ton linker.
OK. Merci. Après quelques recherches sur mon éditeur de lien (ld),
j'ai fini par trouver comment le faire.
En fait, ça ne fonctionne toujours pas. J'ai bien mis les fichiers annexes dans une bibliothèque (libannexe.a). Je compile mes sources avec : cc -o api.o -lannexe -c api.c Mais les fonctions annexes sont toujours utilisables avec api.o.
Le 4/01/07 19:05, dans
<1167933934.752302.70950@s80g2000cwa.googlegroups.com>, « xdunat »
Lorsque je livrerai la librairie libapi on pourra utiliser les
fonctions f1, f2 mais aussi mes sous fonctions. Au départ j'avais t out
mis dans le même fichier et mis les sous fonctions comme "static",
mais le fichier devient trop grand.
Tu mets toutes tes fonctions annexes dans des sources séparés et tu les
places dans une bibliothèque. Ensuite tu prends ton source avec tes 2
fonctions et tu fais une édition de lien partiel avec ta bibliothèq ue. Il ne
restera en extern que tes fonctions. Regarde la doc de ton linker.
OK. Merci. Après quelques recherches sur mon éditeur de lien (ld),
j'ai fini par trouver comment le faire.
En fait, ça ne fonctionne toujours pas.
J'ai bien mis les fichiers annexes dans une bibliothèque
(libannexe.a).
Je compile mes sources avec :
cc -o api.o -lannexe -c api.c
Mais les fonctions annexes sont toujours utilisables avec api.o.
Lorsque je livrerai la librairie libapi on pourra utiliser les fonctions f1, f2 mais aussi mes sous fonctions. Au départ j'avais t out mis dans le même fichier et mis les sous fonctions comme "static", mais le fichier devient trop grand.
Tu mets toutes tes fonctions annexes dans des sources séparés et tu les places dans une bibliothèque. Ensuite tu prends ton source avec tes 2 fonctions et tu fais une édition de lien partiel avec ta bibliothèq ue. Il ne restera en extern que tes fonctions. Regarde la doc de ton linker.
OK. Merci. Après quelques recherches sur mon éditeur de lien (ld),
j'ai fini par trouver comment le faire.
En fait, ça ne fonctionne toujours pas. J'ai bien mis les fichiers annexes dans une bibliothèque (libannexe.a). Je compile mes sources avec : cc -o api.o -lannexe -c api.c Mais les fonctions annexes sont toujours utilisables avec api.o.
Antoine Leca
Sais pas si c'est encore d'actualité...
xdunat wrote:
deux fonctions sont écrit dans un fichier api.c (et api.h). Le problème c'est que c'est deux fonctions sont assez conséquentes, et donc font appel à d'autres sous fonctions défini dans source.c (et le fichier d'entete source.h).
Lorsque je livrerai la librairie libapi on pourra utiliser les fonctions f1, f2 mais aussi mes sous fonctions.
Oui.
Au départ j'avais tout mis dans le même fichier et mis les sous fonctions comme "static", mais le fichier devient trop grand. Comment puis-je faire pour que seul les fonctions souhaitées soit réutilisables ?
Solution 1 : le fichier api.c #inclut source.c (ou d'autres), et tu gardes les static. Ainsi tu obtiens le même effet qu'avec un seul fichier source, mais tu peux découper en plusieurs sous-fichiers ce qui facilite un peu la lecture et la maintenance. Au niveau de la compilation tu es obligé de recompiler tout (en fait api.c) à chaque fois, ce qui te dispense par ailleurs de faire un Makefile :-).
Solution 2 : tu donnes des noms abscons aux fonctions de source.c; en général on appelle cela « décorer », et dans la pratique cela revient à ajouter un préfixe spécifique, par exemple aPi_interne() au lieu de interne(). Tu es obligé de parier : a) sur le fait que personne ne va lier avec une autre bibliothèque qui utilise aussi le même préfixe aPi_ (pas un problème en pratique, sauf pour quelques préfixes trop courrus comme string_) ; b) sur le fait que les utilisateurs ne court-circuitent pas ton API officielle.
En réalité, il n'y a aucune différence entre ce dernier problème, et l'utilisation par tes utilisateurs d'un comportement non documenté (comme par exemple ce qui se passe si une chaîne passée est vide, ou est égale à NULL ; ou un paramètre nul qui renvoit une valeur infinie). Mais pour des raisons qui m'échappent, les programmeurs attachent beaucoup d'importance /a priori/ à ce problème de noms exportés (alors que la solution /a posteriori/ est en général simple, il suffira de tancer les imp[r]udents), et aucune ou presque au changement de comportement dans les situations indéfinies (alors que les solutions sont souvent beaucoup plus difficiles à trouver : que faire par exemple si pour les exemples ci-dessus, une nouvelle version de libapi implémente un mécanisme d'exceptions...)
Antoine
Sais pas si c'est encore d'actualité...
xdunat wrote:
deux fonctions sont écrit dans un fichier api.c (et api.h).
Le problème c'est que c'est deux fonctions sont assez conséquentes,
et donc font appel à d'autres sous fonctions défini dans source.c (et
le fichier d'entete source.h).
Lorsque je livrerai la librairie libapi on pourra utiliser les
fonctions f1, f2 mais aussi mes sous fonctions.
Oui.
Au départ j'avais tout
mis dans le même fichier et mis les sous fonctions comme "static",
mais le fichier devient trop grand.
Comment puis-je faire pour que seul les fonctions souhaitées soit
réutilisables ?
Solution 1 : le fichier api.c #inclut source.c (ou d'autres), et tu gardes
les static. Ainsi tu obtiens le même effet qu'avec un seul fichier source,
mais tu peux découper en plusieurs sous-fichiers ce qui facilite un peu la
lecture et la maintenance.
Au niveau de la compilation tu es obligé de recompiler tout (en fait api.c)
à chaque fois, ce qui te dispense par ailleurs de faire un Makefile :-).
Solution 2 : tu donnes des noms abscons aux fonctions de source.c; en
général on appelle cela « décorer », et dans la pratique cela revient à
ajouter un préfixe spécifique, par exemple aPi_interne() au lieu de
interne(). Tu es obligé de parier :
a) sur le fait que personne ne va lier avec une autre bibliothèque qui
utilise aussi le même préfixe aPi_ (pas un problème en pratique, sauf pour
quelques préfixes trop courrus comme string_) ;
b) sur le fait que les utilisateurs ne court-circuitent pas ton API
officielle.
En réalité, il n'y a aucune différence entre ce dernier problème, et
l'utilisation par tes utilisateurs d'un comportement non documenté (comme
par exemple ce qui se passe si une chaîne passée est vide, ou est égale à
NULL ; ou un paramètre nul qui renvoit une valeur infinie).
Mais pour des raisons qui m'échappent, les programmeurs attachent beaucoup
d'importance /a priori/ à ce problème de noms exportés (alors que la
solution /a posteriori/ est en général simple, il suffira de tancer les
imp[r]udents), et aucune ou presque au changement de comportement dans les
situations indéfinies (alors que les solutions sont souvent beaucoup plus
difficiles à trouver : que faire par exemple si pour les exemples ci-dessus,
une nouvelle version de libapi implémente un mécanisme d'exceptions...)
deux fonctions sont écrit dans un fichier api.c (et api.h). Le problème c'est que c'est deux fonctions sont assez conséquentes, et donc font appel à d'autres sous fonctions défini dans source.c (et le fichier d'entete source.h).
Lorsque je livrerai la librairie libapi on pourra utiliser les fonctions f1, f2 mais aussi mes sous fonctions.
Oui.
Au départ j'avais tout mis dans le même fichier et mis les sous fonctions comme "static", mais le fichier devient trop grand. Comment puis-je faire pour que seul les fonctions souhaitées soit réutilisables ?
Solution 1 : le fichier api.c #inclut source.c (ou d'autres), et tu gardes les static. Ainsi tu obtiens le même effet qu'avec un seul fichier source, mais tu peux découper en plusieurs sous-fichiers ce qui facilite un peu la lecture et la maintenance. Au niveau de la compilation tu es obligé de recompiler tout (en fait api.c) à chaque fois, ce qui te dispense par ailleurs de faire un Makefile :-).
Solution 2 : tu donnes des noms abscons aux fonctions de source.c; en général on appelle cela « décorer », et dans la pratique cela revient à ajouter un préfixe spécifique, par exemple aPi_interne() au lieu de interne(). Tu es obligé de parier : a) sur le fait que personne ne va lier avec une autre bibliothèque qui utilise aussi le même préfixe aPi_ (pas un problème en pratique, sauf pour quelques préfixes trop courrus comme string_) ; b) sur le fait que les utilisateurs ne court-circuitent pas ton API officielle.
En réalité, il n'y a aucune différence entre ce dernier problème, et l'utilisation par tes utilisateurs d'un comportement non documenté (comme par exemple ce qui se passe si une chaîne passée est vide, ou est égale à NULL ; ou un paramètre nul qui renvoit une valeur infinie). Mais pour des raisons qui m'échappent, les programmeurs attachent beaucoup d'importance /a priori/ à ce problème de noms exportés (alors que la solution /a posteriori/ est en général simple, il suffira de tancer les imp[r]udents), et aucune ou presque au changement de comportement dans les situations indéfinies (alors que les solutions sont souvent beaucoup plus difficiles à trouver : que faire par exemple si pour les exemples ci-dessus, une nouvelle version de libapi implémente un mécanisme d'exceptions...)
