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