为何需从Haskell Stack/Cabal的build-deps移除`ekg`才能在Windows找到DLL？

针对你在Windows 64位环境下，使用Stack v1.7.1构建Haskell 7.10项目遇到的Missing C library: tdsodbc错误，以及移除ekg才能找到DLL的疑惑，我来帮你逐一分析和解决：

一、排查tdsodbc.dll找不到的核心问题 #

1. 确认链接器所需的文件类型 #

Windows下的GHC链接器（基于MinGW）默认会优先寻找导入库（.lib/.a文件），而非直接使用DLL。你只放置了tdsodbc.dll，可能缺少对应的导入库：

• 可以用gendef工具从tdsodbc.dll生成.def文件，再通过MinGW的dlltool生成导入库libtdsodbc.a，将这个文件和DLL一起放到项目的lib目录中。
• 或者临时将项目lib目录添加到系统的LIB环境变量中，让链接器能直接识别到DLL的位置。

2. 验证Stack的路径配置是否生效 #

虽然你在stack.yaml和.cabal中都配置了extra-lib-dirs: lib，但要注意：

• 确保.cabal中的配置放在正确的组件段（比如library或executable下），全局配置可能不会被目标组件继承。
• 尝试清理构建缓存后重新构建：

  stack clean && stack build --verbose
  

  查看verbose输出里的configure命令，确认--extra-lib-dirs参数确实指向了你的项目lib目录，且路径没有拼写错误（Windows路径注意转义或用正斜杠）。

3. 检查环境变量与工具链兼容性 #

• Stack在Windows下会自带MinGW工具链，你可以尝试将tdsodbc.dll和导入库复制到Stack的MinGW lib目录中（比如%APPDATA%\stack\programs\x86_64-windows\mingw-w64-x86_64-7.3.0-rt_v5-rev0\mingw64\lib，路径根据你的Stack版本调整），绕开路径配置问题做测试。
• 确保系统PATH中没有其他32位的tdsodbc.dll，避免架构不匹配导致的冲突。

二、关于移除ekg才能找到DLL的疑惑 #

ekg包会影响构建环境的核心原因可能有两个：

1. 路径覆盖或优先级冲突：ekg自身的构建配置可能会添加额外的库搜索路径，或者修改Cabal的链接器参数优先级，导致你配置的extra-lib-dirs: lib被覆盖或忽略。
2. 依赖库的间接影响：ekg依赖的某些C库（比如libcurl或其他系统库）可能会改变链接器的搜索逻辑，甚至和tdsodbc存在隐性的依赖冲突。

你可以通过以下方式验证：

• 分别在有ekg和无ekg的情况下，运行stack build --verbose，对比两次输出中的configure和链接命令，重点看--extra-lib-dirs参数是否有变化，以及链接器的库搜索顺序差异。

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