在Debian上，由于FASL与实际安装的SBCL版本不匹配，我在/ usr / lib / sbcl / site-systems中安装了一堆无法加载的文件。
由于某些原因，这些文件都没有与任何Debian软件包相关联（这是一台运行了十年以上相同Debian安装程序的旧计算机，位于Debian Sid上）。
我一次删除了一个坏系统，对于大多数系统，Quicklisp做正确的事情并下载了Quicklisp版本。有时，ASDF会坚持认为该系统应该位于其先前的路径中，但是重新启动SBCL可以解决该问题。
但是对于一个系统，ASDF始终将其.asd文件的位置缓存在/ usr / lib / sbcl / site-systems /目录中。无法加载该系统，因为即使重新启动SBCL，ASDF也不会在其他地方显示。
我尝试查找在/ etc / common-lisp下的各种配置文件中指定的所有路径。这些文件都不包含对现在缺少的库的引用。
我已对grep -rli下的所有文件进行了/usr的访问。我不希望它在一天之内完成，并且可能找不到任何东西，在这种情况下，我将被迫重新配置整个硬盘，这可能需要一整周的时间。希望缓存不会被压缩，因为那样我再也找不到了。
有人碰巧知道ASDF如何持久化文件的路径吗？
答案 0 :(得分：2)
经过大量艰苦的调试之后，我发现/ usr / lib / sbcl / site-systems /中的文件确实存在。它们是断开的符号链接。
我删除的文件位于符号链接指向的外观类似的路径/ usr / lib / sbcl / site /中。
删除符号链接可修复所有加载错误。
答案 1 :(得分：1)
有关对Quicklisp进行故障排除的一些想法，尤其是在您出现异常行为的情况下。
如果长时间使用Quicklisp，则最终可能会使用本地软件包（默认情况下位于此处，~/quicklisp/local-projects）将您的项目符号链接到该目录是有效的。当然，如果您重命名了一个项目，请不要忘记创建一个新的符号链接并删除旧的符号链接
同样，如果您重命名本地项目，还请删除系统索引，Quicklisp会在下次运行该索引时重新创建该系统索引：~/quicklisp/local-projects/system-index.txt不时删除它只是为了保持正常。您的系统是全新的。
您的*.fasl文件也会变得过时，删除系统缓存会迫使quicklisp重新编译所有内容。在运行SBCL的Ubuntu系统上，这意味着删除以下内容：
rm -rf ~/.cache/common-lisp
(ql:update-client)
可能有必要删除〜/ quicklisp并重新安装Quicklisp本身。 （调试和使用Swanks查找定义功能时，可能会无意间编辑源文件，从而破坏了以前可以正常使用的已安装软件包。这并不是说我会做得如此粗心。）
此外，请不要忘记ASDF会下降到寻找*.asd文件的目录中。如果您的流浪者结构不当，可能会对您的构建系统造成破坏。 （请参阅上面有关将本地项目注册到Quicklisp的评论）
最后，不要忘了检查您的Lisp初始化文件，例如.sbclrc，以解决您可能遗忘的任何调试或快速而肮脏的骇客。
这些都是一次或一次为我工作的所有东西，希望我不会永久保留传奇，对事物的伪装早已得到解决！