J´ai fait une librairie en . so qui est utilisé par mon executable. Le probleme c´est qu´il ne la trouve pas alors qu´elle est dans le repertoire courant. POur que çà fonctionne, je dois copier le . so dans un repertoire connu du / etc/ld.so.conf ou bien definir le chemin dans le LD_LIBRARY_PATH. Je trouve çà un peu moyen comme solution.

Y´a t´il une solution pour obtenir le meme resultat que sous windows avec les DLL ? C´est a dire qu´il cherche en premier dans le repertoire courant avant d´aller dans les dossiers de libraries.

Et puis par la meme occasion : http://www.zythum-project.com
Je cherche un peu de main d´oeuvre pour le portager Linux.

ben tu peut peut etre utilsier le . bashrc et specifier le LD_LIBRARY_PATH non?

Beh, c´est ça la hierarchie d´un systeme UNIX, quand tu installes un outil, les librairies tu les mets dans un dossier de lib, les executables dans un / bin, les fichier de conf dans un / share, etc...

Apres tu peux toujours changer le dl_path ´à la volé´, mais faut voit si c´est vraiment utile.

ben tu peut peut etre utilsier le . bashrc et specifier le LD_LIBRARY_PATH non?

Il me semble que . bashrc n´est lu que par le bash non ? Auquel cas ca signifierait qu´il faudrait le faire pour les shells installés, ca me parait pas top. A moins qu´il y ait un fichier commun pour tout les shells.

Beh, c´est ça la hierarchie d´un systeme UNIX[...]

Oui c´est bien ce qui me fait peur.
J´ai les executables, les librairies dynamiques et les datas, je devrais mettre mes fichiers où avec cette fameuse philosophie ?

Tu peux mettre l´option -L. à la compilation mais ce n´est peut-être pas ce que tu veux...

oui bashrc est lu que par bash ; mais bon tu le met comme shell par defaut et hop non?

pourquoi tu veut pas mettre tes libs dans / usr/local/lib
enfin tu peut aussi rajouter une ligne au / etc/ld.so.conf ; )

Il s´agit là d´un produit qui sera distribué sous la forme de RPM et TAR.GZ, il est donc evident que je dois adapter ce projet a la philosophie LINUX.

Donc, pour récapituler :
Je mets :
Les librairies dynamiques dans / usr/local/lib.
Et pour les datas du projet ? / usr/local/monprojet ?

essaie plutot / usr/local/share/monprojet
je sais pas pourquoi mais bon

Arf, regardes un peu dans tes différents répertoires, tu trouveras par toi même quel ´rangement´ te conviens le mieux ; )

Sinon, tu peux toujours modifier la variable d´environnement en cours d´execution:

###

void *handle;

setenv(LD_LIBRARY_PATH, " /home/aeternis/proot_lib");
/ * pour plusieurs path tu peux utiliser:
appendpath(LD_LIBRARY_PATH, " ./1", " ./2");
prependpath(LD_LIBRARY_PATH, " /lib");;

Après tu peux balancer ton dlopen

• /

handle = dlopen ( "pet.so", RTLD_LAZY);

###

J´ai pas testé, mais logiquement, c´est oP. Dans le cas contraire, tu peux passer par un executable shell que tu lances depuis ton programme principal.

. ..
export
LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/home/aeternis
/proot_lib"
. ..

Sinon... je vois pas l´interet de faire ça, à part pour developper sans avoir un accès root, ou bien dans le cas d´une application qui permet aux users de charger dynamiquement leurs lib perso.

A toi de voir. En tout cas, j´espères que tu nous préviendras quand le portage sera finit, qu´on puisse tester votre jeu.

Sinon, tu peux toujours modifier la variable d´environnement en cours d´execution:

Bah vi mais le probleme c´est que c´est déjà trop tard. La resolution des liens se fait pendant la phase de chargement de l´executable.

le ´dlopen´ n´apporte pas d´interet pour la meme raison que cité précédement.

Sinon... je vois pas l´interet de faire ça[...]

Il n´y a pas d´interet, j´ai une philosophie Windows et donc j´ai un peu de mal sous Linux, j´ai encore beaucoup de choses a apprendre. C´est pour çà que j´espere bien que vous allez m´aider dans tout mes petits problemes

Ceci dit, je peux egalement faire une librairie statique, ca va simplifier les choses, mais bon je perds tout l´interet de la maintenance et de l´economie d´espace memoire de l´utilisation d´une dynamique.

Tiens pendant que j´y suis avec le dlopen, hier soir je l´ai utilisé pour charger la . so du mod du jeu, et bien ca ne marche pas et je comprends toujours pas pourquoi. Dans ma . so, j´ai fait une fonction :

extern " C" KMod* AllocMod();

Et bien le dlsym( handle, " AllocMod" ) ; renvoie NULL ! !!
J´arrive pas a comprendre pourquoi ! !! Je l´avais utilisé sur mon autre projet de jeu ( www.t-bots.com) que j´ai lui aussi fierement porté sous Linux et ca marchait nickel.
Quand j´ouvre le fichier . so avec un editeur de texte, la fonction AllocMod n´apparait pas dedans, donc je comprends l´erreur du dlsym(), mais pourquoi n´apparait-elle pas dedans ? ??? Je l´ai pourtant compilée en -shared.

Au passage, existe-il un programme sous Linux pour afficher les entrées d´une . so ?

As tu bien compilé l´executable avec l´option -ldl ? ( celui qui charge la ld).
Quelle option as tu mise avec dlopen pour la résolution des symboles ?
-> Questions inutile si après compilation, c´est null, mais sait on jamais

Une chose: la surchage de fonctions C++ n´est pas possible dans un code C, donc cela pourrait justifier ton problème ?

Balances ta ligne de compilation pour la librairie, et eventuellement le code si c´est pas trop gros ? ; )

De toute façon, si ça vient d´un problème d´interfaçage avec du C++ je pourrais pas t´aider.
Tout ce que je peut te conseiller, c´est de réviser la syntaxe d´`extern C`

-> nm test.so
-> nm test.o

nm permet de lire le contenu d´un code objet.

Grace à ´nm´ j´ai pu voir qu´il manquait des fonctions dans la librairie et j´ai donc trouvé tout de suite que le makefile avait un soucis.

J´avais fait çà :

$(OBJ1)=toto.o
$(OBJ2)=titi.i
mylib.so : $(OBJ1) $(OBJ2)
g++ -shared -o$@ $<

Et en fait il ne linke que toto.o, je croyais que le chevron gauche ´<´ s´occupait de recopier la partie droite des depedances... on dirait qu´il ne prend que le 1er. Ma foi...

Bon, en tout cas ca marche nickel maintenant. Merci beaucoup de votre aide.

Balances ta ligne de compilation pour la librairie, et eventuellement le code si c´est pas trop gros ? ; )

Le code doit tourner aux alentours de 80 000 lignes de C++, je fais un copier coller quand meme ?

j´ignore où tu as lu que $< recopie les dependances. $< ne recopie que la premiere dependance. La meilleur solution est de declarer une variable OBJS " contenant" tous les . o
par exemple:
OBJS = toto.o titi.i
libname = mylib.so
version = 0.1.0
lib = . /$(libname).$(version)
all: $(lib)

$(lib): $(OBJS)
$(CC) -shared -W1,-soname,$(libname) $(OBJS) -o $@
%.o:%.c
$(CC) -c $< #...

j´ignore où tu as lu que $< recopie les dependances[...]

Je n´ai jamais lu, je l´ai juste fait sans savoir.

$(CC) -shared -W1,-soname,$(libname) $(OBJS) -o $@

Ca veut dire quoi -W1,-soname,$(libname) ?

Je connais l´option -W pour les warnings, mais ce bloc là ca veut dire quoi ? Parce que j´ai pas mis...

rtfm

lol

rtfm

? ??

Read The Fucking Manuel...

http://info.astrian.net/jargon/terms/r/RTFM.html

Bah justement. Comme c´est un ´Fucking´ manuel, je prefere ne pas le lire. Ca fait parti des choses de Linux que je ne supporte pas. Devoir se taper une doc en ´vim´ me fou hors de moi, y´a 20 ans en arriere je comprendrais, mais on est en 2004 non ? Là dessus, MSDN est une tuerie, on ne peut pas reprocher çà à Microsoft.

En attendant que la communauté Linuxienne se décide a faire une documentation correcte, je vais aller m´enerver un peu sur le ´man´.

Sympa l´expression RTFM, je ne connaissais pas.

je ne vois pas ce que certains reprochent à `man`! Si tu veux une interface WEB, il y a plusieurs sites internet qui regroupent les pages+d´autres docs ( google est ton ami)