[Mono] Librairie C et C#

Version imprimable

05/06/2008, 18h06
ced600

[Mono] Librairie C et C#

Bonjour,

Dans le but de faire un Back To Back User Agent (B2BUA) afin de gérer des messages SIP, je vais créer une pile SIP à l'aide d'une libraire C (PJSIP).

Afin de rester sur du C# et de ne pas revenir à du C++, je me suis dis que ce serait cool d'utiliser le framework mono et de m'importer cette petite librairie C. En effet la machine supportant le B2BUA tournera sous linux (et pas autre chose, une question de cout de license).

Oui mais voila, cela parait plus compliqué que ce que je pensais !!!!

D'après ce que j'ai lu, sous windows, en C# je ne peux qu'importer des dll dans un projet grâce à DLLImport.
Bon les développeurs de cette librairie propose une version des source pour ouvrir le projet sous Visual studio c++ 2005, donc créer une dll ne semble pas impossible.

Mais les dll et linux :?

Donc en cherchant à tout hasard si Mono pouvais comprendre des dll, je me suis retrouvé en face d'exemple important des lib natives de linux à l'aide de dllimport. J'ai alors commencé à faire cela :)
Mais pour pouvoir faire :D puis :mrgreen: , il faudrait que je puisse importé de la même manière une librairie non native de linux !!!

Sauriez vous si c possible ?
Si oui une piste pour m'aiguiller dans ma recherche et/ou réalisation ?
Si non une autre solution à me proposer ?

Pour résumer :
J'ai une librarie C, je voudrais l'exploiter dans un code C#, et que la solution fonctionne sous linux avec mono, quitte à devoir recompiler le code en IL sous linux (avec l'editeur du mono-project). Pouvez vous m'aider ?

Je vous remercie par avance.
Ced600.
05/06/2008, 18h45
dev01
Salut.

La réponse est simple : Ta librairie existe telle sous Linux ? Peux tu la recompiler sous Linux avec g++ ?

Si oui à l'un des deux questions alors tu peux créer ton wrapper C->C#. Il te suffit d'utiliser [DllImport("Malib.dll"]. Ensuite dans le fichier de conf sous Linux et tu ajoutes une directive
Code:

1 2 <dllmap dll="mylib.dll" target="mylib.so" />
Il semble qu'il y ai plus simple en ne spécifiant pas l'extension de la dll dans le code C# mais j'ai pas testé.

Le lien chez Mono : http://www.mono-project.com/Interop_...tive_Libraries
06/06/2008, 09h44
ced600

Merci beaucoup, je crois que cette solution me conviens.
Je dispose des sources de la librairie et du makefile, et elle n'est utilisable qu'après recompilation sur l'envirronement d'exécution. En plus, le concepteur de la librairie fournis une documentation clair sur la recompilation.
Bon il propose de compiler avec gcc.
Est ce un problème à ton avis ? Suis je obligé de le faire avec g++ ? Si c'est le cas, g++ devrait être capable de compiler ma librairie c non ?

Et merci pour le lien, il est :king:
J'aurais du chercher un peu sur project-mono :)

Alors : Aligato Gosaimashta
06/06/2008, 21h23
dev01

Citation:

Envoyé par ced600

Est ce un problème à ton avis ? Suis je obligé de le faire avec g++ ? Si c'est le cas, g++ devrait être capable de compiler ma librairie c non ?

Non absolument pas ! Je pensais que c'était du C++ c'est pour ça que je parlais de g++ :D
09/06/2008, 12h04
ced600

:)

Par contre j'ai compilé ma librairie et j'obtiens un fichier .a et non so.
Les fichiers so n'existent ils pas qu'avec le c++.
Je me demande si cela va marcher.
Je vais installer l'environnement de dévellopement aujourd'hui et essayer donc je verrais bien.

Merci en tout cas, je reviendrais sur le sujet si j'ai un problème avec ma lib.

Je me demandais une chose : si j'importe ma lib sous Visual studio c++ et que je compile le projet en librairie (pour obtenir un .so en cas de problème avec le .a), est ce que ma lib a sera intégré à ma lib so, ou y aura t'il juste un lien entre les deux ?
09/06/2008, 20h43
dev01

Citation:

Envoyé par ced600

:)

Par contre j'ai compilé ma librairie et j'obtiens un fichier .a et non so.

De mémoire (il faudrait vérifier) les fichiers .a sont des librairies à lier statiquement. Tu ne peux pas les utiliser avec Mono. Il faut que tu compiles ton projet afin d'avoir une librairie lier dynamiquement ( .so pour shared object ).

Citation:

Envoyé par ced600

Les fichiers so n'existent ils pas qu'avec le c++.

non

Citation:

Envoyé par ced600

Je me demandais une chose : si j'importe ma lib sous Visual studio c++ et que je compile le projet en librairie

alors tu auras un .dll si tu la compiles en dynamique (c'est ce qu'il faut) ou un .lib si tu compiles en statique.

Pour plus d'info je te conseil d'aller faire un tours dans les faq C et C++ de dvp ;)

http://c.developpez.com/faq/?page=di...ERS_lib_header
10/06/2008, 10h29
ced600

Merci de ta réponse.
Je veux bien faire une dll mais je ne pense pas qu'elle fonctionne sous linux.
Maintenant si tu me dis que ce n'est pas important est que mono lui la comprendra, alors je veux bien essayer.
Encore qu'il va falloir que je comprenne comment modifier le MakeFile.

Si cela continue, je vais faire le coeur de ma pile en C++ avec visual (il acceptera alors ma lib statique) et je la compilerais en dynamique (so) pour l'utiliser sur mono et faire un wrapper pour faire le reste de mon application en c#.
10/06/2008, 11h47
dev01

Citation:

Envoyé par ced600

Je veux bien faire une dll mais je ne pense pas qu'elle fonctionne sous linux.

Non si c'est du natif c'est clair. La chose à comprendre c'est que tu doit avoir deux version de ta lib en C : une version windows (.dll) et une version linux ( .so ).
10/06/2008, 13h25
ced600

Ok je comprends.
J'ai regardé mais je crois que je vais être obligé de passer par le dev d'une interface C++ qui utilise ma lib.
Je pourrais alors faire une librairie dynamique so et dll.
je vais regarder un peu mieux le lien que tu m'as fournis, mais puisque mono ne comprendra pas la dll, je me demande si je ne peux pas le bluffer avec une fausse dll et le bon so. Bien qu'il y ait peu d'intérêt à cela vu que de toute façon je comptais créer une dll pour une version windows.
10/06/2008, 14h32
dev01

Citation:

Envoyé par ced600

Ok je comprends.
J'ai regardé mais je crois que je vais être obligé de passer par le dev d'une interface C++ qui utilise ma lib.
Je pourrais alors faire une librairie dynamique so et dll.
je vais regarder un peu mieux le lien que tu m'as fournis, mais puisque mono ne comprendra pas la dll, je me demande si je ne peux pas le bluffer avec une fausse dll et le bon so. Bien qu'il y ait peu d'intérêt à cela vu que de toute façon je comptais créer une dll pour une version windows.

:koi:

Franchement je comprend pas ton problème.
Tu as les sources de la lib C que tu veux utiliser.
Tu peux donc la recompiler une fois sous linux afin d'avoir un .so ( il faut peut etre modifier le Makefile pour cela ) et une deuxième fois pour avoir un .dll sous Windows ( Pareil il faut peut etre modifier la config de VS pour cela ).

Ensuite il ne te reste qu'a coder la partie interop. Tu codes comme si tu ne vises que Windows. La seul différence vient de ce que tu doit ajouter dans le fichier de conf de l'application sous Linux pour que le mappage "nom du fichier .dll dans le programme" -> Fichier .so sous linux fonctionne.

y a rien de compliqué, ça prend 10 mn a tout casser :?

Ok je comprends.
En fait j'ai un problème avec le makefile, c'est que je n'y comprends pas grand chose :( :

Code:

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
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
include build.mak
include build/host-$(HOST_NAME).mak
 
DIRS = pjlib pjlib-util pjnath third_party pjmedia pjsip pjsip-apps
 
ifdef MINSIZE
MAKE_FLAGS := MINSIZE=1
endif
 
all clean dep depend distclean doc print realclean:
	for dir in $(DIRS); do \
		if $(MAKE) $(MAKE_FLAGS) -C $$dir/build $@; then \
		    true; \
		else \
		    exit 1; \
		fi; \
	done
 
LIBS = 	pjlib/lib/libpj-$(TARGET_NAME).a \
	pjlib-util/lib/libpjlib-util-$(TARGET_NAME).a \
	pjnath/lib/libpjnath-$(TARGET_NAME).a \
	pjmedia/lib/libpjmedia-$(TARGET_NAME).a \
	pjmedia/lib/libpjmedia-codec-$(TARGET_NAME).a \
       	pjsip/lib/libpjsip-$(TARGET_NAME).a \
	pjsip/lib/libpjsip-ua-$(TARGET_NAME).a \
	pjsip/lib/libpjsip-simple-$(TARGET_NAME).a \
	pjsip/lib/libpjsua-$(TARGET_NAME).a
BINS = 	pjsip-apps/bin/pjsua-$(TARGET_NAME)$(HOST_EXE) 
 
size:
	@echo -n 'Date: '
	@date
	@echo
	@for lib in $(LIBS); do \
		echo "$$lib:"; \
		size -t $$lib | awk '{print $$1 "\t" $$2 "\t" $$3 "\t" $$6}'; \
		echo; \
	done
	@echo
	@for bin in $(BINS); do \
		echo "size $$bin:"; \
		size $$bin; \
	done
 
#dos2unix:
#	for f in `find . | egrep '(mak|h|c|S|s|Makefile)$$'`; do \
#		dos2unix "$$f" > dos2unix.tmp; \
#		cp dos2unix.tmp "$$f"; \
#	done
#	rm -f dos2unix.tmp
 
xhdrid:
	for f in `find . | egrep '\.(h|c|S|s|cpp|hpp)$$'`; do \
		echo Processing $$f...; \
		cat $$f | sed 's/.*\$$Author\$$/ */' > /tmp/id; \
		cp /tmp/id $$f; \
	done
 
prefix = /usr/local
install:
	mkdir -p $(DESTDIR)$(prefix)/lib
	cp -L $$(find . -name '*.a') $(DESTDIR)$(prefix)/lib
	mkdir -p $(DESTDIR)$(prefix)/include
	cp -RL $$(find  . -name include) $(DESTDIR)$(prefix)
	cd $(DESTDIR)$(prefix)/lib && for i in $$(find . -name 'libpj*a'); do\
		ln -s $$i $$(echo $$i | sed -e "s/-$(TARGET_NAME)//");\
	done
	mkdir -p $(DESTDIR)$(prefix)/lib/pkgconfig
	sed -e "s!@PREFIX@!$(DESTDIR)$(prefix)!" libpj.pc.in > $(DESTDIR)/$(prefix)/lib/pkgconfig/libpj.pc

Le build.mak :

Code:

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
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
# build.mak.  Generated from build.mak.in by configure.
export MACHINE_NAME := auto
export OS_NAME := auto
export HOST_NAME := unix
export CC_NAME := gcc
export TARGET_NAME := i686-pc-linux-gnu
export CROSS_COMPILE := 
export LINUX_POLL := select 
 
# Determine which party libraries to use
export APP_THIRD_PARTY_LIBS := -lresample-$(TARGET_NAME) -lmilenage-$(TARGET_NAME)
 
ifneq (,1)
APP_THIRD_PARTY_LIBS += -lgsmcodec-$(TARGET_NAME)
endif
 
ifneq (,1)
APP_THIRD_PARTY_LIBS += -lspeex-$(TARGET_NAME)
endif
 
ifneq (,1)
APP_THIRD_PARTY_LIBS += -lilbccodec-$(TARGET_NAME)
endif
 
ifneq ($(findstring pa,pa_unix),)
APP_THIRD_PARTY_LIBS += -lportaudio-$(TARGET_NAME)
endif
 
 
# CFLAGS, LDFLAGS, and LIBS to be used by applications
export PJDIR := /root/PJProject/pjproject-0.8.0
export APP_CC := $(CROSS_COMPILE)$(CC_NAME)
export APP_CFLAGS := -DPJ_AUTOCONF=1\
	-O2\
	-I$(PJDIR)/pjlib/include\
	-I$(PJDIR)/pjlib-util/include\
	-I$(PJDIR)/pjnath/include\
	-I$(PJDIR)/pjmedia/include\
	-I$(PJDIR)/pjsip/include
export APP_CXXFLAGS := $(APP_CFLAGS)
export APP_LDFLAGS := -L$(PJDIR)/pjlib/lib\
	-L$(PJDIR)/pjlib-util/lib\
	-L$(PJDIR)/pjnath/lib\
	-L$(PJDIR)/pjmedia/lib\
	-L$(PJDIR)/pjsip/lib\
	-L$(PJDIR)/third_party/lib\
 
export APP_LDLIBS := -lpjsua-$(TARGET_NAME)\
	-lpjsip-ua-$(TARGET_NAME)\
	-lpjsip-simple-$(TARGET_NAME)\
	-lpjsip-$(TARGET_NAME)\
	-lpjmedia-codec-$(TARGET_NAME)\
	-lpjmedia-$(TARGET_NAME)\
	-lpjnath-$(TARGET_NAME)\
	-lpjlib-util-$(TARGET_NAME)\
	$(APP_THIRD_PARTY_LIBS)\
	-lpj-$(TARGET_NAME)\
	-lm -luuid -lnsl -lrt -lpthread  -lasound -lssl -lcrypto
 
export PJ_DIR := $(PJDIR)
export PJ_CC := $(APP_CC)
export PJ_CFLAGS := $(APP_CFLAGS)
export PJ_CXXFLAGS := $(APP_CXXFLAGS)
export PJ_LDFLAGS := $(APP_LDFLAGS)
export PJ_LDLIBS := $(APP_LDLIBS)

qui est générée à partir du build.mak.in :

Code:

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
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
# @configure_input@
export MACHINE_NAME := auto
export OS_NAME := auto
export HOST_NAME := unix
export CC_NAME := gcc
export TARGET_NAME := @target@
export CROSS_COMPILE := @ac_cross_compile@
export LINUX_POLL := @ac_linux_poll@ 
 
# Determine which party libraries to use
export APP_THIRD_PARTY_LIBS := -lresample-$(TARGET_NAME) -lmilenage-$(TARGET_NAME)
 
ifneq (@ac_no_gsm_codec@,1)
APP_THIRD_PARTY_LIBS += -lgsmcodec-$(TARGET_NAME)
endif
 
ifneq (@ac_no_speex_codec@,1)
APP_THIRD_PARTY_LIBS += -lspeex-$(TARGET_NAME)
endif
 
ifneq (@ac_no_ilbc_codec@,1)
APP_THIRD_PARTY_LIBS += -lilbccodec-$(TARGET_NAME)
endif
 
ifneq ($(findstring pa,@ac_pjmedia_snd@),)
APP_THIRD_PARTY_LIBS += -lportaudio-$(TARGET_NAME)
endif
 
 
# CFLAGS, LDFLAGS, and LIBS to be used by applications
export PJDIR := @ac_pjdir@
export APP_CC := $(CROSS_COMPILE)$(CC_NAME)
export APP_CFLAGS := -DPJ_AUTOCONF=1\
	@CFLAGS@\
	-I$(PJDIR)/pjlib/include\
	-I$(PJDIR)/pjlib-util/include\
	-I$(PJDIR)/pjnath/include\
	-I$(PJDIR)/pjmedia/include\
	-I$(PJDIR)/pjsip/include
export APP_CXXFLAGS := $(APP_CFLAGS)
export APP_LDFLAGS := -L$(PJDIR)/pjlib/lib\
	-L$(PJDIR)/pjlib-util/lib\
	-L$(PJDIR)/pjnath/lib\
	-L$(PJDIR)/pjmedia/lib\
	-L$(PJDIR)/pjsip/lib\
	-L$(PJDIR)/third_party/lib\
	@LDFLAGS@
export APP_LDLIBS := -lpjsua-$(TARGET_NAME)\
	-lpjsip-ua-$(TARGET_NAME)\
	-lpjsip-simple-$(TARGET_NAME)\
	-lpjsip-$(TARGET_NAME)\
	-lpjmedia-codec-$(TARGET_NAME)\
	-lpjmedia-$(TARGET_NAME)\
	-lpjnath-$(TARGET_NAME)\
	-lpjlib-util-$(TARGET_NAME)\
	$(APP_THIRD_PARTY_LIBS)\
	-lpj-$(TARGET_NAME)\
	@LIBS@
 
export PJ_DIR := $(PJDIR)
export PJ_CC := $(APP_CC)
export PJ_CFLAGS := $(APP_CFLAGS)
export PJ_CXXFLAGS := $(APP_CXXFLAGS)
export PJ_LDFLAGS := $(APP_LDFLAGS)
export PJ_LDLIBS := $(APP_LDLIBS)

La dedans je ne vois pas où il est dit que la lib doit être en .a .

Bon j'ai bien trouvé d'autre fichier .mak qui contienne du code genre :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
export CC = $(CROSS_COMPILE)gcc -c
export AR = $(CROSS_COMPILE)ar rv 
export LD = $(CROSS_COMPILE)gcc
export LDOUT = -o 
export RANLIB = $(CROSS_COMPILE)ranlib
 
export OBJEXT := .o
export LIBEXT := .a
export LIBEXT2 :=
 
export CC_OUT := -o 
export CC_INC := -I
export CC_DEF := -D
export CC_OPTIMIZE := -O2
export CC_LIB := -l
 
export CC_SOURCES :=
export CC_CFLAGS := -Wall 
#export CC_CFLAGS += -Wdeclaration-after-statement
#export CC_CXXFLAGS := -Wdeclaration-after-statement
export CC_LDFLAGS :=

Est ce là que je dois modifier l'extension de la librairie et lui dire que je veux un .so ? Et si oui est ce qu'il suffit de remplacer .a par .so ?

A vrai dire j'en été arrivé à la conclusion que cela serait plus simple de faire comme j'ai dit avant. Mais en fait c'est faux et en plus cela réduira mes performance. Si à chaque fois que j'appelle une méthode, elle appelle une méthode du SO qui appelle la méthode de la lib a qui appelle des méthodes des libs standards et du système d'exploitation :? , surtout que j'aurais besoin de performance.
Ma pile sip devra être capable d'analyser la requête et en générer une nouvelle en quelques millisecondes.

Si tu as encore une idée sur ce makefile, je suis toutes ouies, et je t'en remercie d'avance.

Ensuite je comparerais le temps de traitement entre un appel via un code C#.net (mono) et l'appel via le code C++ compilé. Si tu as aussi une idée sur les performances dans les deux cas n'hésites pas à me le dire :D

En tout cas si grâce à toi j'arrive à importer la lib en C# je te paye un coup à boire, virtuellement bien sur :mrgreen:

10/06/2008, 20h44
dev01

Citation:

Envoyé par ced600

Est ce là que je dois modifier l'extension de la librairie et lui dire que je veux un .so ? Et si oui est ce qu'il suffit de remplacer .a par .so ?

non c'est pas les même options de compilation.

Citation:

Envoyé par ced600

Ensuite je comparerais le temps de traitement entre un appel via un code C#.net (mono) et l'appel via le code C++ compilé. Si tu as aussi une idée sur les performances dans les deux cas n'hésites pas à me le dire :D

Tu sera forcément perdant avec Mono/.Net. La surcouche managé fait que de toute façon les perfs seront moindre. Maintenant savoir de combien ... ça j'en sais rien

Citation:

Envoyé par ced600

En tout cas si grâce à toi j'arrive à importer la lib en C# je te paye un coup à boire, virtuellement bien sur :mrgreen:

Je peux aussi te passer mon numéro de compte en banque :aie:
11/06/2008, 09h59
ced600

Ok merci.

Je vais chercher sur le net ces options de compilations, et après je m'amuserais avec ce make file :aie:

Je peux te payer en billet de mono poly si tu veux :mouarf:
23/06/2008, 17h11
ced600

Bon pour des besoins de compatibilité et d'intégration avec un code C\C++ dans un future proche (6 mois) je vais devoir faire mon développement en C\C++.

Donc ma question ne se pose plus.