OS X: convert .dylib to .a/.o (dynamic to static)?

Question

Suppose I've read this caveat, and I still want to use TBB as a statically-linked library. (Pretend I'm working in an environment where users aren't allowed to create their own dylibs.) But I don't really want to rewrite the TBB makefile to generate libtbb.a instead of libtbb.dylib.

Is there a simple command-line way to convert libtbb.dylib into libtbb.o with the same entry points?

I have heard a good argument for not being able to go the other way, from static to dynamic. Namely: dynamic libraries need to be PIC, and converting a non-PIC static library to PIC isn't feasible. But that argument doesn't apply in the other direction, as far as I know.

Here's someone saying it's impossible to convert .dll to .a on Windows, but I think they're just talking about the impossibility of breaking a .dll or .exe back up into its original .o files, not necessarily saying it would be impossible to create a linkable .o file with the same contents. Also, the situation on Windows is slightly odder than "real" PIC, although I don't think that's relevant.

Highchair

Answer 1

Intel Threading Building Blocks (TBB) is available as binary for Windows, Mac and Linux. If you expect to use libtbb.dylib from the Mac distribution on iOS then you are out of luck. The Mac distribution is targeted for Intel (32 and 64 bits). Since iOS runs on ARM processors, you could not use it, even if you found a way to convert a dynamic library to a static library.

If you found a libtbb.dylib file somewhere else targeted for ARM, then you could probably use it on iOS. It's actually possible to load dynamic libraries on iOS. Have a look at the dlopen(3) man page.

Finally, you should read about Grand Central Dispatch (GCD) instead, which is built-in support for concurrent code execution on multicore hardware in iOS and OS X.

Disgorge

Upvoted for the GCD reference. Alone that is worth the bounty :) – Evoy

@JavierSoto: I'm 99% confident that dlopen does not work on iOS (although just to increase the confusion I think there's a way to make it work in the simulator). I've heard the rationale that Apple wants apps to be simple and self-contained, and avoid DLL hell in the App Store. If anyone's successfully used a dylib in an iOS app, please comment. – Highchair

Yes, dlopen really works on iOS. You can't easily create dylibs with Xcode but it's possible to create them with clang on the command line. – Disgorge

@0xced: Thanks for the suggestions. TBB is open-source (GPLv2), so there are more than just binaries available. I've successfully built it for ARM already. github.com/Quuxplusone/tbb I don't think GCD can be substituted in our case; we need control over which thread executes which tasks. We use TBB for its concurrent_queue and concurrent_hash_map data structures (basically doing producer/consumer via a concurrent_queue). We could fairly easily swap out TBB for "std::queue protected by a std::mutex", but we suspect TBB's implementation is more efficient and less buggy. – Highchair

@0xced: Was that a response to my "please comment"? Sorry, but I'm still unconvinced. Actually, anyone who's done it successfully should really comment here: #3724356 or here: #3091537 – Highchair

My first comment was a reply to Javier Soto. Dynamically loading code on iOS definitely works on the device too. I have a project where bundles are loaded with -[NSBundle load] which I'm pretty sure eventually calls dlopen. (This project has not been submitted to the App Store.) The code in the bundle or dylib must be signed with the same provisioning profile as the app though. I think Apple concern about dynamic libraries is not the DLL hell, but rather the security implication of downloading and executing code. – Disgorge

Thanks 0xced! Do you think they would approve an app doing that? or dinamically loading code is against the review guidelines? – Sightseeing

@Highchair maybe the design shouldn't care about which threads run which task? The abstraction that GCD provides gives a lot of simplicity by thinking in terms of queues and forgetting about the underlying threads... – Sightseeing

The review guidelines and the developer program license agreement insist that you can not install or download executable code. I think that embedding a dynamic library would be perfectly fine. A legitimate use of dynamically loding code could be to easily support multiple OS versions for example. – Disgorge