2011-12-29 4 views
4

SBCL peut charger hunchentoot avec succès. Cependant, le CCL a rapporté:Pourquoi CCL ne peut-il pas charger hunchentoot?

? (ql:quickload :hunchentoot) 
To load "hunchentoot": 
Load 1 ASDF system: 
hunchentoot 
; Loading "hunchentoot" 
> Error: Unable to load any of the alternatives: 
>   ("libssl.so.0.9.8" "libssl.so" "libssl.so.4") 
> While executing: CFFI::FL-ERROR, in process listener(1). 
> Type :POP to abort, :R for a list of available restarts. 
> Type :? for other options.nter code here 

Toute suggestion est appréciée!

Répondre

7

Si vous n'avez pas besoin ssl (ou utiliserez Apache pour cela), vous pouvez

(push :hunchentoot-no-ssl *features*) 

puis

(ql:quickload 'hunchentoot) 
+0

Ça ne marche toujours pas! –

+1

Désolé, mon erreur. (appuyez sur: fonctions HUNCHENTOOT-NO-SSL *). deux points, pas une seule citation. –

+1

ok, cela fonctionne sans SSL. –

3

Il est à la recherche d'une version de la bibliothèque SSL que vous n'avez pas. Un moyen facile de le corriger (je n'ai pas testé le bon comportement de la bibliothèque elle-même) est de le lier symboliquement. Exécutez ces derniers dans votre shell:

locate libssl

Il devrait retourner quelque chose comme:

/lib/i386-linux-gnu/libssl.so.1.0.0 
/lib/x86_64-linux-gnu/libssl.so.1.0.0 
/usr/lib/firefox-8.0/libssl3.so 
/usr/lib/i386-linux-gnu/libssl.so.1.0.0 
/usr/lib/thunderbird-8.0/libssl3.so 
/usr/lib/x86_64-linux-gnu/libssl.so 
/usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 
/usr/lib/x86_64-linux-gnu/libssl3.so 
/usr/lib/x86_64-linux-gnu/libssl3.so.1d 

celui que vous voulez est certainement /usr/lib/x86_64-linux-gnu, ou similaire , en fonction de votre plate-forme.

Ensuite, créez le lien symbolique:

ln -s libssl3.so libssl.so

remplacement libssl3.so avec la version que vous avez installé.

+0

Sur ma boîte freebsd, il y a un lien:/usr/lib/libssl.so @ -> libssl.so.6, mais pourquoi canot CCL trouve /usr/lib/libssl.so? –

Questions connexes