使用静态链接在Haskell库中与C库进行链接

Question

我有一个Haskell项目，旨在创建一些C++绑定。我已经编写了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文件中，因为这就是我在实际项目中的做法。该项目使用“make”通过Cabal构建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库。没有其他警告或错误。

- Deech

Answer 1

为了解决这个问题，我需要做以下两件事情：

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

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

下面详细解释如何创建一个包含C和Haskell对象的新档案，这并不简单。复杂性出现是因为在构建过程的链接器部分没有办法(至少在Cabal 1.16.0.2中)。

在Cabal文件中设置标志很简单，因此这里不再描述。

重新链接Haskell库

1. 通过添加以下内容将构建类型设置为custom:

   build-type: custom
   

   添加自定义构建逻辑，通过替换Setup.hs中的main方法实现：

   to the cabal file.

2. 将其添加到cabal文件中。

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

完成构建后，会创建一个档案文件，但我们需要重新创建它以包括步骤一中由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 ()

默认的buildHook在第4步中运行，创建了一个临时的包数据库文件，命名为“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

现在我们将复制品的路径存储到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

- Deech