将 C 库与 Haskell 库静态链接

Posted 2023-02-19

【中文标题】将 C 库与 Haskell 库静态链接

【英文标题】：Statically linking a C library with a Haskell library

【发布时间】：2013-09-03 19:01:11

【问题描述】：

我有一个旨在创建一些 C++ 绑定的 Haskell 项目。我已经编写了 C 包装器并将它们编译成一个独立的静态链接库。

我想编写 Haskell 绑定以静态链接到 C 包装器，这样我就不必单独分发 C 包装器，但我似乎无法让它工作，希望能得到一些帮助。

我将 C 库指定为额外库，但我的 cabal build 步骤似乎没有将其添加到编译命令中。

我创建了一个小项目来说明这一点 (http://github.com/deech/CPlusPlusBindings)。

它包含一个小型 C++ 类 (https://github.com/deech/CPlusPlusBindings/tree/master/cpp-src)、C 包装器 (https://github.com/deech/CPlusPlusBindings/tree/master/c-src)、一个有效的 C 测试例程 (https://github.com/deech/CPlusPlusBindings/tree/master/c-test) 和 Haskell 文件 (https://github.com/deech/CPlusPlusBindings/blob/master/src/BindingTest.chs)。

C 库是在 Setup.hs 中添加的，而不是在 Cabal 文件中，因为这是我的真实项目，它在构建步骤之前通过 Cabal 使用“make”构建 C 库。我已经验证在构建步骤中，BuildInfo 的 extraLibs 部分包含库名称，extraLibDirs 包含正确的目录。

我的cabal build 的输出是：

creating dist/setup
./dist/setup/setup build --verbose=2
creating dist/build
creating dist/build/autogen
Building CPlusPlusBinding-0.1.0.0...
Preprocessing library CPlusPlusBinding-0.1.0.0...
Building library...
creating dist/build
/usr/local/bin/ghc --make -fbuilding-cabal-package -O -odir dist/build -hidir dist/build -stubdir dist/build -i -idist/build -isrc -idist/build/autogen -Idist/build/autogen -Idist/build -I/home/deech/Old/Haskell/CPlusPlusBinding/c-src -I/home/deech/Old/Haskell/CPlusPlusBinding/cpp-includes -optP-include -optPdist/build/autogen/cabal_macros.h -package-name CPlusPlusBinding-0.1.0.0 -hide-all-packages -package-db dist/package.conf.inplace -package-id base-4.6.0.1-8aa5d403c45ea59dcd2c39f123e27d57 -XHaskell98 -XForeignFunctionInterface BindingTest
Linking...
/usr/bin/ar -r dist/build/libHSCPlusPlusBinding-0.1.0.0.a dist/build/BindingTest.o
/usr/bin/ar: creating dist/build/libHSCPlusPlusBinding-0.1.0.0.a
/usr/bin/ld -x --hash-size=31 --reduce-memory-overheads -r -o dist/build/HSCPlusPlusBinding-0.1.0.0.o dist/build/BindingTest.o
In-place registering CPlusPlusBinding-0.1.0.0...
/usr/local/bin/ghc-pkg update - --global --user --package-db=dist/package.conf.inplace

不幸的是，编译和链接步骤都没有使用 C 库。没有其他警告或错误。

【参考方案1】：

为了解决这个问题，我必须：

重新链接 Haskell 库与 C 绑定的目标文件和 在我的Cabal 文件中使用ghc-options 标记以确保它们以正确的顺序链接。

所有更改都在测试项目中 (http://github.com/deech/CPlusPlusBindings)。

下面详细解释了创建包含 C 和 Haskell 对象的新存档的过程，并不简单。之所以会出现这种复杂性，是因为（从 Cabal 1.16.0.2 开始）无法挂钩到构建过程的链接器部分。

在 Cabal 文件中设置标志是微不足道的，因此这里不再描述。

重新链接 Haskell 库

通过添加将构建类型设置为custom：

build-type: custom

到 cabal 文件。

通过将Setup.hs 中的main 方法替换为：

main = defaultMainWithHooks simpleUserHooks 
              buildHook = myBuildHook, 
              ...
       

这告诉构建过程，与其使用simpleUserHooks 中定义的默认构建过程，不如使用下面定义的myBuildHook 函数。同样，清理过程被自定义函数 myCleanHook 覆盖。

定义构建钩子。此构建挂钩将在命令行上运行 make 以构建 C++ 和 C 部分，然后在创建链接 Haskell 绑定时使用 C 目标文件。

我们开始myBuildHook:

myBuildHook pkg_descr local_bld_info user_hooks bld_flags = do

首先运行make，不带参数：

rawSystemExit normal "make" []

然后将头文件和库目录的位置以及库本身添加到PackageDescription 记录中，并使用新的包描述更新LocalBuildInfo：

let new_pkg_descr = (addLib . addLibDirs . addIncludeDirs $ pkg_descr)
    new_local_bld_info = local_bld_info localPkgDescr = new_pkg_descr

在buildHook 触发之前，configureHook 将编译顺序存储在LocalBuildInfo 记录的compBuildOrder（组件构建顺序）键中。我们需要隔离库的构建，因此我们将构建过程的库构建和可执行构建部分分开。

构建顺序只是一个列表，如果构建组件只是一个普通的 CLibName 类型构造函数，我们知道它是一个库，因此我们将这些元素从列表中隔离出来，并仅用它们更新 LocalBuildInfo 记录：

let (libs, nonlibs) = partition
                       (\c -> case c of
                                CLibName -> True
                                _ -> False)
                       (compBuildOrder new_local_bld_info)
    lib_lbi = new_local_bld_info compBuildOrder = libs

现在我们运行带有更新记录的默认构建钩子：

buildHook simpleUserHooks new_pkg_descr lib_lbi user_hooks bld_flags

构建完成后，已创建存档，但我们必须重新创建它以包含由步骤 1 中的 make 命令生成的 C 对象。因此，我们获取一些设置和 C 对象文件路径列表：

let verbosity = fromFlag (buildVerbosity bld_flags)
info verbosity "Relinking archive ..."
let pref = buildDir local_bld_info
    verbosity = fromFlag (buildVerbosity bld_flags)
cobjs <- getLibDirContents >>= return . map (\f -> combine clibdir f) 
                                      . filter (\f -> takeExtension f == ".o")

然后将其交给withComponentsLBI，它作用于构建的每个组件。在这种情况下，因为我们只处理库部分，所以只有一个组件。 Cabal 提供 getHaskellObjects 用于获取 Haskell 目标文件的列表，createArLibArchive 用于创建存档，以便我们可以重新运行链接器：

 withComponentsLBI pkg_descr local_bld_info $ \comp clbi ->
  case comp of
    (CLib lib) -> do
              hobjs <- getHaskellObjects lib local_bld_info pref objExtension True
              let staticObjectFiles = hobjs ++ cobjs
              (arProg, _) <- requireProgram verbosity arProgram (withPrograms local_bld_info)
              let pkgid = packageId pkg_descr
                  vanillaLibFilePath = pref </> mkLibName pkgid
              Ar.createArLibArchive verbosity arProg vanillaLibFilePath staticObjectFiles
    _ -> return ()

在第 4 步中运行的默认 buildHook 创建了一个名为“package.conf.inplace”的临时包数据库文件，其中包含所构建库的描述，以便可执行文件可以链接它而无需库安装到默认的系统包文件中。不幸的是，每次buildHook 运行都会将其空白，因此我们需要保留一个临时副本：

  let distPref  = fromFlag (buildDistPref bld_flags)
      dbFile = distPref </> "package.conf.inplace"
 (tempFilePath, tempFileHandle) <- openTempFile distPref "package.conf"
 hClose tempFileHandle
 copyFile dbFile tempFilePath

现在我们将该副本的路径连同在步骤 3 中过滤掉的构建过程的可执行部分一起存储到 LocalBuildInfo 结构中。

  let exe_lbi = new_local_bld_info 
                  withPackageDB = withPackageDB 
                                    new_local_bld_info ++ 
                                   [SpecificPackageDB tempFilePath], 
                  compBuildOrder = nonlibs
                

并将路径再次存储在PackageDescription 的extraTmpFiles 部分中，以便可以通过默认清理挂钩将其删除。

exe_pkg_descr = new_pkg_descr extraTmpFiles = extraTmpFiles new_pkg_descr ++ [tempFilePath]

现在我们终于在可执行组件上再次运行默认的buildHook，并使用更新的记录（现在知道新存档）：

buildHook simpleUserHooks exe_pkg_descr exe_lbi user_hooks bld_flags