0

我似乎走在试错的道路上，在我之前的其他人试图创建一组新的 MonoMac 绑定。和其他人一样，我已经解决了一些问题，但最终被卡住了。

此时创建了绑定 dll，但是当它被消耗时，我在该线程的标题中得到错误。看起来关键是 EntryPointNotFoundException。如果我在 Xamarin Studio 中使用程序集浏览器，我会看到 DllImports 如下所示[DllImport(, EntryPoint = )]：我不确定缺少的程序集名称和入口点值是否只是因为它是内部类型而浏览器不会显示这些。但这是突出的一件事......

底层库是本机 C++，我只得到了标题和静态 library.a 文件。@Stephane Delcroix 有一篇关于如何为 MonoTouch（不是 MonoMac）生成绑定的优秀文章。@poupou 有一个MonoMac 的绑定示例，但从 Objective-C 开始。我想出的生成文件如下所示：

MONOMAC=/GitHub/MonoMac/src/MonoMac.dll
MCS=mcs
SWIG=swig
XBUILD=xcodebuild

CONFIGURATION=Release
LIB=libulapi.a
WRAPPER_PROJECT=ulapi_wrapper/ulapi_wrapper.xcodeproj
WRAPPER=libulapi_wrapper.a

all: UlApi.dll

debug: CONFIGURATION = Debug
debug: all

.SUFFIXES:
.SUFFIXES: .i .h .cs .mm

%.mm: %.i headers/ulfactory.h
    @mkdir -p generated
    $(SWIG) -c++ -csharp -namespace UlApi -dllimport __Internal -outdir generated -o $@  $<
    # Deal with reverse callbacks and fixup leading underscore on exports
    ruby fixup_generated_cs.rb generated/UlApiPINVOKE.cs > generated/UlApiPINVOKE_fixed.cs
    $(RM) generated/UlApiPINVOKE.cs
    mv generated/UlApiPINVOKE_fixed.cs generated/UlApiPINVOKE.cs

$(WRAPPER): ulapi.mm $(WRAPPER_PROJECT)
    # -sdk macosx
    $(XBUILD) -project $(WRAPPER_PROJECT) -target ulapi_wrapper -arch i386 -configuration $(CONFIGURATION) clean build
    -mv ulapi_wrapper/build/$(CONFIGURATION)/$(WRAPPER) $@

UlApi.dll: $(LIB) $(WRAPPER)
    $(MCS) -noconfig -o- -out:$@ -res:$(LIB) -res:$(WRAPPER) generated/*.cs -target:library -unsafe -r:System -r:System.Core -r:$(MONOMAC)

clean: 
    $(RM) $(WRAPPER) *.dll

clean-generated:
    $(RM) -r generated *.mm

clean-all: clean clean-generated

.PHONY: clean clean-all clean-generated

我和其他人了解到的一个不明显的变化是 xcodebuild 中需要“-arch i386”。在 xcode 中创建的静态库的默认值是 64 位，所以在那里也进行了更改。一旦你以 i386 为目标，你需要关闭 ARC（你实际上可以构建以 x86_64 为目标的 dll，并确保在生成的 mm 文件中 __bridge 任何（void *）NSObjects 强制转换，但听起来 i386 是从我见过......包括“ MonoMac 绑定尚未移植到 64 位”）。

我必须做的另一件事是，我的静态库包装器项目是在导出时使用前导下划线生成的（使用“ nm libulapi_wrapper.a”发现。Swig 的输出 UlApiPINVOKE.cs 文件将 EntryPoint 映射到没有有前导下划线所以我在“修复”红宝石文件中添加了更多逻辑来修补该下划线。

看起来可能与加载 dylib 的内容有关……请参见此处和此处，但不确定具体是什么。

欢迎任何建议！

4

1 回答 1

1

最终解决，特别感谢 Xamarin 支持的 Brendan Zagaeski。Brendan在这里写下了解决方案的精髓。这是从开始到结束对该过程的解释的地方。

解决方案中关键不明显部分的简短摘要：

  • 在我的案例中，最大的问题是即使包装器正在构建 i386，源库也是为 x64 构建的......doh！这种绑定的最佳来源是通过 dylib 而不是静态存档。
  • 不需要像为 iOS 所做的那样修复回调。
  • 包装库也被创建为 dylib。
  • dylib 都是从文件系统加载的（不是通过嵌入式资源）。
  • 需要修复“安装名称”路径才能找到库。
于 2014-05-12T14:22:57.300 回答