使用Cabal Freeze文件跨机器构建失败，依赖冲突求助

核心原因 #

你的问题出在Cabal的依赖解析策略上：它默认会优先选择本地已安装的包，而非严格按照freeze文件从Hackage下载对应版本。错误日志里的unix-2.7.2.2/installed-2.7.2.2明确显示，Cabal选用了第二台机器上已安装的unix包——这个包是和本地的bytestring-0.11.3.1编译绑定的，因此它的实际依赖约束是固定为bytestring-0.11.3.1，而非unix包声明的<0.12宽松范围。

这就导致了矛盾：freeze文件要求bytestring==0.11.4.0，但已安装的unix包只能配合bytestring-0.11.3.1使用，两边无法兼容。

你对Cabal Freeze的误区 #

1. Freeze文件锁定依赖版本组合，但不强制忽略本地已安装包：Freeze的作用是记录原机器上能正常构建的依赖版本，但Cabal默认会优先复用本地已安装的包（哪怕版本和freeze不一致），因为它默认认为已安装包是可用的。
2. 已安装包的实际依赖约束比包声明更严格：包声明的依赖范围（比如unix的bytestring <0.12）是编译前的允许范围，但一旦包被编译安装，它就和当时使用的具体依赖版本绑定了，实际运行/构建时只能用那个版本，不能随便替换成同范围内的其他版本。

解决方法 #

方法1：强制Cabal忽略已安装包，按freeze文件重新构建 #

执行以下命令，强制Cabal重新下载并编译freeze文件指定的所有依赖，完全不依赖本地已安装的包：

cabal build --reinstall --avoid-reinstalls=false

如果使用的是新版Cabal（3.0+），也可以用隔离构建模式，彻底隔离本地已安装包的干扰：

cabal build --enable-isolated

方法2：卸载冲突的本地包 #

先卸载第二台机器上冲突的unix和bytestring版本，再执行cabal build，让Cabal按照freeze文件下载并编译正确的版本组合：

cabal uninstall unix-2.7.2.2 bytestring-0.11.3.1
cabal build

方法3：生成适配本地环境的freeze文件（不推荐，会改变依赖版本） #

如果你不需要严格和原机器一致，也可以删除现有freeze文件，在第二台机器上重新运行cabal freeze，生成适合本地已安装包的依赖锁定文件：

rm cabal.project.freeze
cabal freeze
cabal build

额外建议 #

要想跨机器实现完全一致的构建，最好使用隔离式构建环境：

• 新版Cabal的--enable-isolated选项会自动创建独立的构建环境，不依赖全局已安装包。
• 也可以使用Nix来管理Haskell依赖，Nix会为每个项目构建完全独立的依赖环境，彻底避免跨机器的依赖差异问题。

内容的提问来源于stack exchange，提问作者user855443