静态链接C库和Haskell库

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).

在Setup.hs中添加了C库,而不是在Cabal文件中,因为这就是我的实际项目,它在构建步骤之前使用"make"通过Cabal构建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

要解决这个问题,我不得不:

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

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

下面详细解释了创建包含C和Haskell对象的新存档的过程,这并不简单.之所以出现这种复杂性是因为没有办法(如Cabal 1.16.0.2那样)挂钩构建过程的链接器部分.

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

重新调整Haskell库

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

   build-type: custom
   

   到cabal文件.

2. 通过替换以下main方法插入自定义构建逻辑Setup.hs:

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

   这告诉构建过程不要simpleUserHooks使用myBuildHook其中定义的默认构建过程,而应使用下面定义的函数.同样,使用自定义函数覆盖清理过程myCleanHook.

3. 定义构建钩子.此构建挂钩将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存储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}
   

4. 现在我们使用更新的记录运行默认构建挂钩:

   buildHook simpleUserHooks new_pkg_descr lib_lbi user_hooks bld_flags
   

5. 一旦完成构建已创建存档,但我们必须重新创建它以包含make步骤1中的命令生成的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 ()
   

6. 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
   

7. 现在,我们将该副本的路径LocalBuildInfo与构建过程的可执行部分一起存储到结构中,这些部分已在步骤3中过滤掉.

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

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

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

8. 现在,我们最终buildHook再次使用更新的记录(现在知道新存档)再次运行默认值:

   buildHook simpleUserHooks exe_pkg_descr exe_lbi user_hooks bld_flags