在ios上调用dlopen [英] Calling dlopen on ios

问题描述

这是一个备受关注的话题，尤其是最近的话题。希望这不是一个骗局，因为我已经讨论了所有其他的SO问题。

This is a much talked about subject, particularly of late. Hopefully this isn't a dupe as I've gone over all the other SO questions.

我对这是否合法不感兴趣。虽然你不能100％清楚你是否可以在iOS8上使用dylib自由地做你想要的东西，但它似乎允许一些动态加载（参见例如你能为iOS构建动态库并在运行时加载吗？。

I'm not interested in whether this is legal or not. Whilst it's not 100% clear whether you can freely do what you want with a dylib on iOS8, it appears some amount of dynamic loading is allowed (see for example Can you build dynamic libraries for iOS and load them at runtime?).

我关心的只是让dlopen工作（暂时忘记商店提交）！我有一个非常基本的iOS示例，我手动执行dlopen，然后使用dlsym在本地dylib中调用函数。这在模拟器上工作正常但在设备上失败。该设备是iPhone 4s运行（非越狱）iOS 7.1.2。

What I care about is just making dlopen work (forget store submissions for now)! I've got a very basic iOS example where I manually do a dlopen followed by a dlsym to call a function in a homegrown dylib. This works fine on the simulator but fails on device. The device is an iPhone 4s running (non-jailbroken) iOS 7.1.2.

AFAIK即使在iOS 7上调用dlopen也是合法的，因为有明确的Apple指令如何支持这一点（请参阅将iOS版本部署到旧版iOS https://developer.apple.com/library/prerelease/ios/documentation/General/Conceptual/ExtensibilityPG/ExtensionScenarios.html# // apple_ref / DOC / UID / TP40014214-CH21-SW3 ）。

AFAIK it is legal to call dlopen even on iOS 7 as there are explicit Apple instructions for how to support this (see "Deploying a Containing App to Older Versions of iOS" here https://developer.apple.com/library/prerelease/ios/documentation/General/Conceptual/ExtensibilityPG/ExtensionScenarios.html#//apple_ref/doc/uid/TP40014214-CH21-SW3).

我的猜测是根本原因很简单，比如dylib位于iOS不喜欢二进制文件的文件夹中。有没有人有这方面的经验，知道有什么限制，或者可能知道我做错了什么。

My guess is the root cause is something simple, like the dylib being in a folder which iOS doesn't like for binaries. Does anyone have any experience doing this and know what the restrictions are, or possibly knows what I'm doing wrong.

我的加载代码是：

NSString* resourcePath = [[NSBundle mainBundle] resourcePath];
NSString* dlPath = [NSString stringWithFormat: @"%@/frameworktest", resourcePath];
const char* cdlpath = [dlPath UTF8String];
void* hModule = dlopen(cdlpath, RTLD_LAZY);

dylib（frameworktest）是通过创建Cocoa Touch Framework，从中构建和获取dylib二进制文件来创建的。构建的框架并添加到项目资源（在根文件夹中）。 otool将dylib显示为针对ios min版本7.0的armv7 dynmic库。我也可以成功地打开文件，所以我知道我正在查找正确的文件夹。

The dylib (frameworktest) was created by creating a Cocoa Touch Framework, building and grabbing the dylib binary from the built framework and adding to the project resources (in the root folder). otool shows the dylib as an armv7 dynmic library targeting ios min version of 7.0. I can successfully fopen the file as well so I know I'm looking in the right folder.

我可以深入了解dlopen程序集。到目前为止，它变得没有信息，寻找明显的失败：）

I can step deep into the dlopen assembly. So far in fact that it became uninformative looking for obvious fails :)

任何想法？

推荐答案

在调用dlopen之后检查errno我看到EPERM（我猜这不是一个大惊喜）。

Checking errno after the call to dlopen I see EPERM (not a big surprise I guess).

我在构建中添加了一个代码签名阶段，以明确签署dylib，现在可以正常工作了。

I've added a codesign phase to the build to explicity sign the dylib and it works now.

一些额外信息：有趣的是，应用程序的签名阶段默认运行在整个.app包上，而不仅仅是主应用程序二进制文件（从未仔细查看过） 。所以人们可能会期望这也会签署dylib。事实上，当我的自定义阶段运行codesign报告替换现有签名时。然而，这可能来自框架的原始构建。我检查了该项目的阶段，并且框架也被签署（再次，不仅仅是dylib，而是将整个框架传递给codesign）。符号参数是相同的。所以，沿着小道的某个地方，我想是dylib签名不正确。如果有任何有趣的信息，我会在某些时候对此进行更详细的调查并发回。我的猜测是我通过手动创建，提取和打包dylib来打破系统！

Some extra info: Interestingly, the sign phase for the app defaults to running over the whole .app bundle, not just the main app binary (never looked closely at that). So one might expect this to sign the dylib as well. In fact, when my custom phase runs codesign reports "replacing existing signature". However this might be coming from the original build of the framework. I checked the phases for that project and the framework is also signed (again, not just the dylib but the whole framework is passed to codesign). The sign parameters are the same. So somewhere along the trail the dylib is getting signed incorrectly I guess. I'll investigate this in more detail at some point and post back if there's any interesting info. My guess is I'm breaking the system by manually creating, extracting and packaging the dylib!

感谢@jww和@duskwuff的建议！

Thanks to @jww and @duskwuff for the suggestions!

这篇关于在ios上调用dlopen的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！