Re: undefined symbol in foreign library

Pascal Bourguignon a écrit :

> Est-on sur que la libgsl est déjà chargée dans clisp?
> 
> 
Pardon je crois que j'ai compris votre question de travers.
Qu'entendez-vous par "déjà chargée" ? On donne le chemin de la libgsl, 
    puis le moyen de pointer sur des fonctions ou des variables de cette 
bibliothèque avec les formats des paramètres et valeurs de retour. De 
mémoire je crois que c'est réalisé avec les fonctions posix "dynamic 
link" [dlfcn(), dlopen(), etc...]. Dans le cas de mon problème les mêmes 
composants fonctionnaient bien, avant que je change les paths d'accès à 
ma bibliothèque [reposant maintenant en ~/lib figurant dans $LD_LIB_PATH 
(j'ai plus le nom exact en tête)] dont certaines fonctions font 
elles-même appel à la libgsl (reposant en /usr/local/lib).
Par ailleurs les fichiers lisp ne sont pas encore compilés afin d'éviter 
la rémanence de situations antérieures.
Revenant sur la libgsl, la plainte à l'exécution concerne la première 
invocation rencontrée dans le fichier qui utilise la libgsl (allocation 
d'un buffer de travail). A noter que les pointeurs de ces buffers, au 
nombre de trois (wavetable, real, halfcomplex) font partie de la 
structure opaque de cette classe. Je l'ai souhaité ainsi après avoir 
longuement hésité car en faire des variables de classe plutôt que 
d'instance conduisait à figer les dimensions d'un paramètre de l'objet ; 
génant pour l'application.
A noter encore qu'il fut un temps où je me souviens avoir eu des 
problèmes de segmentation à cause de ces paramètres. Inexpliqués 
(changeant l'ordre des trois invocations faisait disparaitre le 
problème. Passé le programme à la moulinette de "electric fence" ne 
permettait pas de déceler d'anomalies ??? Pas très sain j'en conviens 
mais c'était il y a très longtemps et depuis tout semblait tourner comme 
une horloge jusqu'à ce que ... vous connaissez la suite, et ce n'est 
plus du lisp mais du C.
Est-ce que c'est plus proche de votre question ?
AMn