Discussion :

[sinfoni]

Bonjour à tous,

J'ai écrit une fonction en C. Je souhaite maintenant pouvoir exporter cette fonction afin de pouvoir l'appeler depuis une autre programme écrit en Pascal.

Je ne connais pas du tout C, et je n'ai donc aucune idée de la structure que doit avoir mon programme C.

A ce stade, il compile et génère un exécutable (unix car je travaille sous Mac OS X). Dans mon programme Pascal, cet exécutable est bien trouvé lors du linkage. En revanche, si j'appelle ma fonction depuis mon programme Pascal, le compilateur renvoie cette erreur:

Undefined symbols:
"_GetBSDProcessListSimple", referenced from: _PC_GETPROCESS$TSTRINGLIST$$LONGINT in PC.o

Voici le code si cela peut aider:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
 
#include "mnifun.h"
#include <assert.h>
#include <errno.h>
#include <stdbool.h>
#include <stdlib.h>
#include <stdio.h>
#include <sys/sysctl.h>
 
 
typedef struct  {
	pid_t	p_pid;			/* Process identifier. */
	char	p_comm[128]; 
} procsimple;                   
 
typedef struct kinfo_proc kinfo_proc;
 
class TestLib
{
public:
	int (procsimple ** proclistsimple, size_t *procCount);
};
 
 
 
int GetBSDProcessListSimple(procsimple ** proclistsimple, size_t *procCount)
{
	int err, i, j;
	kinfo_proc *       process;
	size_t             ProcCount;
 
    err = GetBSDProcessList(&process, &ProcCount);
	*proclistsimple = (procsimple*)malloc(ProcCount * sizeof(procsimple));
	for (i=0; i< ProcCount; i++) {
		(*proclistsimple)[i].p_pid = process[i].kp_proc.p_pid;
		for (j=0; j<MAXCOMLEN+1; j++) {
			(*proclistsimple)[i].p_comm[j] = process[i].kp_proc.p_comm[j];
		}
	}			
	free(process);
	return err;
};

Comment déclarer proprement la fonction GetBSDProcessListSimple pour que je puisse l'importer depuis un autre programme (C ou Pascal) sachant que je souhaite que le linkage soit statique ?

Merci d'avance,
André.

PS: Post initialement placé dans sous-forum .net par erreur.

[adcid]

Est-tu sûr de ton coup?
Logiquement, compiler le pascal apres le C et tenter de faire référence à une fonction de l'exécutable C est...impossible, à moins que ta fonction C soit dans le main et ne fasse que ça. (et à moins que je ne me gourre complètement)

Sinon, tu fais ça, tu pipe les programme :

Code :

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

prog1 [args] | prog2 [args]

et tu fais en sorte que le C ne fasse que ta fonction par exemple avec un menu auquel repond le prog pascal (suffit d'ajouter le chiffre du menu avant tes variables).

Par contre, c'est juste pour passer des variables... je vois pas comment faire autrement.

[sinfoni]

Heu... Si tu veux, ce que je souhaite faire est ce qu'on ferait sous Windows en créant un DLL. Je crée ma DLL en C et j'appelle les fonctions de ma DLL depuis mon programme Pascal (ou n'importe quel autre langage d'ailleurs). Donc ça c'est possible parce que je l'ai déjà fait

Ici, je ne suis pas sous windows, mais sous Mac OSX, et par commodité, pour ne pas à avoir à distribuer plusieurs fichiers, je souhaite faire une liaison statique et non dynamique.

[ok.Idriss]

Bonsoir.

Comme dit, je doute également que tu ne puisse faire autrement que ceci :

- Tu appel ta fonction C dans la fonction main () en récupérant les paramètres de celle-ci (qui seront renseignés lors de l'exécution du programme).
- Tu fait en sorte d'exécuter ton programme C en lui passant les paramètres depuis ton programme pascal ...

Sinon, es-tu sûr que tu fait bien du C et pas du C++ ?

Code :

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

1
2
3
4
class TestLib
{
        public:    int (procsimple ** proclistsimple, size_t *procCount);
};

ça c'est pas du C ...

Cordialement,
Idriss

[sloshy]

Bonjour,
La compilation est un ensemble d'outil et d'etape.
Le but du jeu est de generer du code objet a partir de la source en C.
Ensuite d'utiliser ce code objet lors de l'edition de lien dans le processus de compilation de la source pascal.

Code :

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

1
2
hostname% gcc -c my_c.c
hostname% pc -calign my_c.o my_pascal.p

Voila, c'est tout

[sinfoni]

Bonsoir.

Comme dit, je doute également que tu ne puisse faire autrement que ceci :

- Tu appel ta fonction C dans la fonction main () en récupérant les paramètres de celle-ci (qui seront renseignés lors de l'exécution du programme).
- Tu fait en sorte d'exécuter ton programme C en lui passant les paramètres depuis ton programme pascal ...

Sinon, es-tu sûr que tu fait bien du C et pas du C++ ?



ça c'est pas du C ...

Cordialement,
Idriss

Pour moi C, C++... j'avoue ne pas trop faire la nuance. C++ est objet (classes etc.) et pas C ? Peu importe pour moi s'il me faut faire C++ ou C.

@ok.Idriss et @adcid : Je suis vraiment très surpris par vos réponses. Je NE VEUX PAS faire un programme C qui sera appelé par un programme PASCAL. Je veux faire ce que je fais tous les jours avec des bibliothèques C (C++ ???) existantes: du LINKING, dynamique ou statique. Comment pouvez-vous douter de la faisabilité de cette chose alors que c'est un principe de base ??? Je dois certainement mal m'exprimer:

Quand je programme en Pascal ou en Progress (yet another language) sous windows, si j'ai besoin d'une fonction de l'API, ben je la prends via un linking dynamic, bref, je charge la DLL, et j'appelle la fonction qui m'intéresse. Ici, je veux faire exactement la même chose à deux détail prés:

1. Je n'utilise pas un kernel32.dll ou autre mais mon propre code C
2. Le linking doit être statique (donc fait lors de la compilation) puisque c'est mon propre code (donc ma librairie C ne sera pas sur l'ordinateur de mon voisin, il faut donc que je la lui livre, et je ne veux pas lui livrer 2 fichiers mais un seul)

@sloshy
Je comprends bien le processus de construction. Mais n'y a-t-il rien à faire au niveau du code en C (C++ ???) pour rendre la fonction exportable. Je m'explique: Quand on code une fonction, on n'a pas forcément envie que n'importe qui l'importe et l'utilise. En Pascal, on choisit donc explicitement ce qu'on souhaite rendre accessible. Lors de la phase d'édition des liens, seules les fonctions explicitement publiées sont accessibles.

Dans l'exemple de la déclaration de la fonction GetBSDProcessListSimple, n'y a-t-il aucun mot clé à mettre spécifiquement pour dire au compilateur:

"je souhaite que GetBSDProcessListSimple soit exportée au standard stdcall ou cdecl" ?

Par ailleurs, es-tu sûr que le code objet d'un compilateur A est exploitable par un compilateur B ? Dans mon cas, je compile ma library C avec Xcode et je compile mon projet sous Lazarus/FPC. Ne dois-je pas plutôt générer un pur executable unix ?

André

[sloshy]

Pour moi C, C++... j'avoue ne pas trop faire la nuance. C++ est objet (classes etc.) et pas C ? Peu importe pour moi s'il me faut faire C++ ou C.

Le C est un langage imperatif, le C++ est une modification du C pour que le langage soit oriente objet (ca fais beaucoup de difference).
Les compilateurs actuelles sont capables de gerer les deux langages en un (comme sun et sa tablette ^^)

@ok.Idriss et @adcid : Je suis vraiment très surpris par vos réponses. Je NE VEUX PAS faire un programme C qui sera appelé par un programme PASCAL. Je veux faire ce que je fais tous les jours avec des bibliothèques C (C++ ???) existantes: du LINKING, dynamique ou statique. Comment pouvez-vous douter de la faisabilité de cette chose alors que c'est un principe de base ??? Je dois certainement mal m'exprimer:

Non tu t'es bien exprime ...

Quand je programme en Pascal ou en Progress (yet another language) sous windows, si j'ai besoin d'une fonction de l'API, ben je la prends via un linking dynamic, bref, je charge la DLL, et j'appelle la fonction qui m'intéresse. Ici, je veux faire exactement la même chose à deux détail prés:

1. Je n'utilise pas un kernel32.dll ou autre mais mon propre code C
2. Le linking doit être statique (donc fait lors de la compilation) puisque c'est mon propre code (donc ma librairie C ne sera pas sur l'ordinateur de mon voisin, il faut donc que je la lui livre, et je ne veux pas lui livrer 2 fichiers mais un seul)

C'est bien ce que ma solution propose

@sloshy
Je comprends bien le processus de construction. Mais n'y a-t-il rien à faire au niveau du code en C (C++ ???) pour rendre la fonction exportable. Je m'explique: Quand on code une fonction, on n'a pas forcément envie que n'importe qui l'importe et l'utilise. En Pascal, on choisit donc explicitement ce qu'on souhaite rendre accessible. Lors de la phase d'édition des liens, seules les fonctions explicitement publiées sont accessibles.

Dans l'exemple de la déclaration de la fonction GetBSDProcessListSimple, n'y a-t-il aucun mot clé à mettre spécifiquement pour dire au compilateur:

"je souhaite que GetBSDProcessListSimple soit exportée au standard stdcall ou cdecl" ?

Je comprend pas, tu as une fonction, tu crees un fichier objet de cette fonction, puis quand tu compiles ton programme pascale, tu lie le fichier objet ce qui aura pour but de faire un linkage statique et de placer ta fonction dans la table d'export, elle sera ainsi accessible partout et donc depuis ton code pascal, c'est ce que tu souhaites (?)
Tu pourrais en C dire que ta fonction ne peut pas etre exportable (les fonctions statique a un fichier) et/ou les declarer dans un fichier header et inclure le fichier header dans certains fichiers C pour restreindre la portee de ta fonction, mais tu ne veux pas faire du C si? (j'avoue etre un peu perdu)

Par ailleurs, es-tu sûr que le code objet d'un compilateur A est exploitable par un compilateur B ? Dans mon cas, je compile ma library C avec Xcode et je compile mon projet sous Lazarus/FPC. Ne dois-je pas plutôt générer un pur executable unix ?

André

Je ne connais pas tous les compilateurs (a ne pas confondre avec les IDE) mais oui, tous les fichiers objets sont utilisables par tous les compilateurs (je dirais meme que c'est leur fonction premiere)
puisqu'un fichier objet n'a plus de rapport avec la source de l'application (c'est un code binaire lie a l'OS et l'architecture).