如何说服mkbundle包含MonoPosixHelper？

Question

该系统反过来使用依赖于MonoPosixHelper的Mono特性

我的问题是mkbundle无法识别依赖关系，我最终得到的可执行文件仍然需要动态链接到~/bin/lib/libMonoPosixHelper.so，当我将此可执行文件移动到没有安装Mono的系统时，会导致问题。实际上，捆绑包缺少一个它应该静态链接的东西。

这违背了嵌入式可执行文件的用途...我希望能够将这个程序作为一种服务器提供给人们，他们可以放在任何地方并以二进制文件的形式启动，显然，如果他们需要安装库才能工作，服务器并不是完全独立的！

我看到了如何强制mkbundle包含程序所依赖的任何dll文件，但是MonoPosixHelper不是作为dll存在的；它是一个仅供Linux使用的库，并且只作为共享库存在。有没有人知道一种“强制”包静态嵌入的方法？

如果这有帮助，我的小编译脚本如下所示：

mcs -debug+ IdaTester.cs Isis.cs -r:System.dll -r:Microsoft.CSharp.dll -r:Mono.Posix.dll
mkbundle --static -o IdaTester IdaTester.exe --deps

然后我运行IdaTester；这在可以找到libMonoPosixHelper库的平台上工作，但如果在没有安装libMonoPosixHelper的平台上运行，则在运行时尝试动态加载该库将失败……

Answer 1

需要将libMonoPosixHelper.so与应用程序一起分发，并更改dll映射才能使其工作。

有关问题的背景-在运行时加载库

libMonoPosixHelper不是静态链接的，而是作为P/Invoke调用进行搜索和加载的，如下例所示：

    [DllImport ("MonoPosixHelper")]
    static extern int zipClose (ZipHandle handle, string globalComment);

也就是说，它只在运行时被请求，而不是在编译时，因此不能提前链接。

修复它-分发libMonoPosixHelper.so

需要四个步骤。

1. 将libMonoPosixHelper复制到将用于分发程序的目录。
2. 更新DllMap配置文件以避免硬编码捆绑
3. 将包含libMonoPosixHelper.so的路径添加到安装计算机上的LD_LIBRARY_PATH中。

要执行每项操作：

1.将libMonoPosixHelper复制到将用于分发程序的目录。

libMonoPosixHelper通常位于lib文件夹中，只需将其复制到要创建tarball的文件夹中即可。

cp $MONO_ROOT/lib/libMonoPosixHelper.so ~/MY_PROGRAM/

2.更新DllMap配置文件以避免硬编码位置。

这是避免硬编码路径问题的关键。我们需要在mkbundle中嵌入一个配置文件，但不指定路径。为此，首先找到mono配置文件，并将其复制到本地目录

cp $MONO_ROOT/etc/mono/config ~/MY_PROGRAM/config

现在我们需要修改这个文件以删除dll的特定路径，使用您喜欢的编辑器打开它，并更改路径以避免使用特定的前缀：

<dllmap dll="MonoPosixHelper" target="MACHINE_SPECIFIC/lib/libMonoPosixHelper.dylib" os="!windows" />

至

<dllmap dll="MonoPosixHelper" target="libMonoPosixHelper.dylib" os="!windows" />

mkbundle 3.使用嵌入配置文件

将以下选项添加到mkbundle命令，以嵌入新编辑的配置文件：

   --config MY_PROGRAM/config

4.将带有libMonoPosixHelper.so的路径添加到安装计算机上的LD_LIBRARY_PATH。

现在，您可以压缩mkbundled可执行文件、libMonoPosixHelper.so和任何其他文件以进行分发。当解压并在机器上运行时，dlopen现在将像任何其他dll一样查找libMonoPosixHelper.so。因此，只需向其LD_LIBRARY_PATH环境变量添加包含您的分布式libMonoPosixHelper版本的任何目录

Answer 2

这两个似乎都不理想:前者迫使我“接触”Mono发行版，这会产生更长期的维护问题，而后者迫使我进入更复杂的发行版和安装模式。但是，似乎一旦生成了共享库，就不能静态地链接到该库的版本；Linux加载器只是在处理更多标准库的方式中不会将库视为库。

相反，如果我从相同的.o文件生成一个标准库，加载器将乐于静态链接到它，并且因为mxbundle最终运行cc并因此使用标准ld，所以这个选项对我来说是有效的。所以我想这就是我问题的答案。