c++ - 将 C 库与 Haskell 库静态链接

Question

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

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

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

我创建了一个小项目来说明这一点(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 库。我已经在构建步骤验证了 extraLibs BuildInfo 的一部分包含库名称和 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 库。没有其他警告或错误。

Answer 1

为了解决这个问题，我不得不:

用 C 绑定(bind)的目标文件和

重新链接 Haskell 库

使用 ghc-options在我的 Cabal 中标记文件以确保它们以正确的顺序链接。

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

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

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

重新链接 Haskell 库

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

build-type: custom

到 cabal 文件。

通过替换 main 插入自定义构建逻辑Setup.hs 中的方法和:

main = defaultMainWithHooks simpleUserHooks {
              buildHook = myBuildHook, 
              ...
       }

这告诉构建过程不要使用 simpleUserHooks 中定义的默认构建过程。它应该使用 myBuildHook下面定义的函数。类似地，清理过程被自定义函数 myCleanHook 覆盖。 .

定义构建 Hook 。此构建 Hook 将运行 make在命令行上构建 C++ 和 C 部分，然后在创建链接 Haskell 绑定(bind)时使用 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将编译顺序存储在 compBuildOrder LocalBuildInfo 的(组件构建顺序)键记录。我们需要隔离库的构建，因此我们将构建过程的库构建和可执行构建部分分开。

构建顺序只是一个列表，如果它只是一个普通的 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}

现在我们使用更新的记录运行默认的构建钩子(Hook):

buildHook simpleUserHooks new_pkg_descr lib_lbi user_hooks bld_flags

构建完成后，已创建存档，但我们必须重新创建它以包含由 make 生成的 C 对象。步骤 1 中的命令。所以我们获取一些设置和 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结构以及在步骤 3 中过滤掉的构建过程的可执行部分。

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

并将路径再次存储在 extraTmpFiles PackageDescription 的一部分因此可以通过默认清理 Hook 将其删除。

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

现在我们终于运行默认的 buildHook再次使用可执行组件上的更新记录(现在知道新存档):

buildHook simpleUserHooks exe_pkg_descr exe_lbi user_hooks bld_flags