在Swift模块中使用C库的链接器架构错误。

时间:2021-10-24 09:43:20

I have an xcode workspace with the following structure:

我有一个xcode工作区,其结构如下:

  • A C library iGLPK compiled into a framework (dynamic or static, the error persists)

    编译为框架的C库iGLPK(动态或静态,错误持续)

  • A dynamic framework SwiftyGLPK which has iGLPK as a linked framework and provides a Swift wrapper to use the C library

    一个动态框架SwiftyGLPK,将iGLPK作为链接框架,并提供一个快速包装器来使用C库

  • An xcode project Frozen which has SwiftyGLPK as a linked framework

    一个冻结的xcode项目,它有一个作为链接框架的SwiftyGLPK

  • The code that uses the SwiftyGLPK library is in a separate framework target Model_GLPK within the Frozen project. This framework compiles fine.

    使用SwiftyGLPK库的代码位于冻结项目中的单独框架target Model_GLPK中。这个框架运行良好。

The problem comes when I write code within the main Frozen/ViewController that calls on Model_GLPK and hence down to the C library underneath - it does not compile and produces this linker error:

当我在主要的冻结/ViewController中编写代码时,问题就出现了,这个代码调用Model_GLPK,因此一直到下面的C库——它没有编译并产生这个链接器错误:

Undefined symbols for architecture arm64:
  "SwiftyGLPK.SolveGoal.Minimise (SwiftyGLPK.SolveGoal.Type) -> SwiftyGLPK.SolveGoal", referenced from:
  Frozen.ViewController.viewDidLoad (Frozen.ViewController)() -> () in ViewController.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I get the same result on the simulator and on device, just the architecture that's not found changes.

我在模拟器和设备上得到了相同的结果,只是没有发现变化的架构。

I also tried extracting the files from the Model_GLPK framework and putting them directly into the Frozen target. Now everything compiles fine and there is no longer a linking error, but instead I get a hard crash on run

我还尝试从Model_GLPK框架中提取文件,并将它们直接放入冻结的目标中。现在所有的东西都编译得很好,并且不再有链接错误,相反,我在运行时遇到了严重的崩溃

dyld`dyld_fatal_error:
->  0x1200c1088 <+0>: brk    #0x3

after this instruction:

在这个指令:

dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*, unsigned long*)

dyldbootstrap::start(macho_header const*, int, char const*, long, macho_header const*, unsigned long*)

Can anyone shed light on what's going on?

有人能解释一下发生了什么事吗?

1 个解决方案

#1


1  

I found a solution, but not an explanation.

我找到了解决办法,但没有解释。

I built up the workspace step by step again, starting from having the C library compiled directly inside the main project which worked, then extracting it into a framework, then extracting its Swift wrapper into its own framework, then creating an internal module linked to the wrapper.

我一步一步地构建了工作区,从让C库直接编译到工作的主项目中,然后将它提取到一个框架中,然后将它的Swift包装器提取到自己的框架中,然后创建一个与包装器相关的内部模块。

Now everything works but I still have no idea why or what's different from before. The whole thing feels really fragile. ¯_(ツ)_/¯

现在一切正常,但我仍然不知道为什么和以前有什么不同。整件事让人感觉很脆弱。¯_(ツ)_ /¯

This article on module maps for static libraries was helpful, as was this one. Also this build settings reference.

这篇关于静态库的模块映射的文章很有帮助,就像这篇文章一样。还有这个构建设置引用。

#1


1  

I found a solution, but not an explanation.

我找到了解决办法,但没有解释。

I built up the workspace step by step again, starting from having the C library compiled directly inside the main project which worked, then extracting it into a framework, then extracting its Swift wrapper into its own framework, then creating an internal module linked to the wrapper.

我一步一步地构建了工作区,从让C库直接编译到工作的主项目中,然后将它提取到一个框架中,然后将它的Swift包装器提取到自己的框架中,然后创建一个与包装器相关的内部模块。

Now everything works but I still have no idea why or what's different from before. The whole thing feels really fragile. ¯_(ツ)_/¯

现在一切正常,但我仍然不知道为什么和以前有什么不同。整件事让人感觉很脆弱。¯_(ツ)_ /¯

This article on module maps for static libraries was helpful, as was this one. Also this build settings reference.

这篇关于静态库的模块映射的文章很有帮助,就像这篇文章一样。还有这个构建设置引用。