为何部分外部函数静态链接、部分动态链接？及libgit2的FFI调用问题

一、为何部分外部函数采用静态链接，另一些采用动态链接？ #

其实这两种链接方式各有优劣，完全是根据实际需求来选择的：

• 选静态链接的常见场景：
  • 想要程序独立运行，不用依赖目标机器上的动态库——比如你写了个小工具要发给别人用，静态打包后对方直接就能跑，不用额外装依赖，特别方便。
  • 怕动态库版本冲突——比如不同程序依赖同个库的不同版本，静态链接把依赖直接打包进程序，就不会出现“版本不兼容”的问题。
  • 追求一点点性能提升——静态链接的函数在编译时就确定了地址，运行时不用再动态解析，虽然提升不大，但对某些敏感场景还是有用的。
• 选动态链接的常见场景：
  • 省空间！多个程序可以共享同一份动态库的内存实例，磁盘上也只存一份，比如系统里的libc几乎所有程序都用动态链接，能省超多资源。
  • 方便更新依赖——要是库出了bug或者加了新功能，直接替换动态库文件就行，不用重新编译整个主程序，对大型项目或者频繁更新的库来说太香了。
  • 依赖的是大型系统级库——像libssl、libcurl这类，系统本身就自带，动态链接直接用系统的就行，不用自己打包进去。

二、Haskell通过FFI调用libgit2时出现断言失败的排查方向 #

我之前用Haskell调用C库也遇到过类似的断言问题，给你几个实用的排查点：

1. 先核对FFI的参数类型是否完全匹配
   别小看这个，很多时候就是类型对应错了！比如Haskell的CString是不是对应C里的const char*？Ptr GitRepository是不是和C里的git_repository*布局一致？还有整数类型（比如CInt vs int）、布尔值这些，一定要严格对应，差一点就可能触发断言。
2. 检查libgit2的初始化步骤
   libgit2要求必须先调用git_libgit2_init()才能用，用完还要git_libgit2_shutdown()。你在纯C程序里肯定加了，但Haskell这边是不是漏了？比如在程序启动时没初始化，直接调用git_update_repo，那大概率会触发断言。
3. 盯紧资源的生命周期
   Haskell的GC是自动的，如果你把Haskell管理的内存指针传给C函数，GC可能在C函数还在运行时就把这块内存回收了，这绝对会出问题。可以用withForeignPtr来固定内存，或者在调用完C函数后用touch告诉GC别着急回收。另外，C函数里创建的git资源（比如仓库指针）是不是没正确释放？也可能导致后续调用出问题。
4. 拿到完整的断言错误信息
   你说断言内容未完成，尽量想办法拿到完整的报错——比如libgit2的断言会打印出具体的文件和行号（比如repo.c:456: assertion 'repo != NULL' failed）。如果Haskell程序没输出，可以在C代码里加printf调试，或者用gdb attach到Haskell进程，看调用栈里的具体位置，这能直接帮你定位是哪个参数出了问题。
5. 排查线程安全问题
   libgit2大部分函数不是线程安全的，而Haskell的Runtime是多线程的。如果你的FFI声明用的是unsafe（默认），多个线程可能同时调用这个函数，直接触发断言。可以把FFI声明改成safe，或者在Haskell这边加个锁，确保同一时间只有一个线程操作git资源。
6. 检查libgit2的编译配置
   你编译libgit2的时候是不是开了debug模式（默认会开启断言），而Haskell链接的libgit2和C程序用的不是同一个版本？比如C程序用的是debug版，Haskell链接的是release版，或者反过来，也可能导致断言行为不一致。

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