Merge Mach-O executable with a static lib?

Question

Suppose you have

1. a pre-built iOS executable app (for simulator or device).
2. a pre-built static archive library static library which among other things contains c++ static initializers.

Now it should be possible to merge the two built products to produce the a new iOS executable which is like the old one, except that it is now also linked with the additional static library, and on execution will run the static library's static initializers.

Which tool (if any) could help solve this merge problem?

Edit: An acceptable solution is also to dynamically load the library using dlopen. The whole purpose of this is for application testing, so the re-linked app will never see app store.

Lubricator

Sounds like something you should be able to do with the standard linker. I've not done anything like that for years though. A good start would be man pages, finding some examples of statically linked libraries via the commandline, and to start you off looking at the commandline output of linking a basic project with that library added. – Swarthy

No it the standard linker, ld, is not able to link with an executable: ld: can't link with a main executable for architecture i386 – Lubricator

how were you able to build the ios app in the first place without the static library? I am a bit confused here... – Samba

The pont is that I don't have the project source code. Someone else has build an ARM .ipa or a i386 .app, and I want to link in a static (or dynamically loaded) library on the binary. This is for testing purposes. – Lubricator

Something like that can be done by deassembling, hacking the assembly language and rebuilding. A huge job, with dubious results. That if doing this is even allowed by the licenses involved. And @slycrel, the linker won't do it for you. Why would it, it's use case is completely different. – Furry

@Furry Agreed it is a very different use case than what the standard linker is for. In the end though all the linker does is attach object code together to make an executable. Adding additional code -could- be possible with a linker, but I've never done it before. It may totally not work, that's why it was a comment, not an answer, I was just trying to give some helpful places to start looking for a self-found answer. Thanks for the correction. As to the main problem, a debugger attached might be able to load some dynamic method swizzling code but that would be fairly complex as well. – Swarthy

@slycrel, once the linker has done its work it throws away (most of) the infomation in the *.o that is needed to do the stitching together to give an executable, as it won't be used anymore. – Furry

Answer 1

How a compiler work (in a simple explanation)

The most popular C++ compilers (like say, GCC), work by translating all the C++ (and Obj-C, C, etc...) code to ASM.

Then it calls the appropriate assembler for the target processor, and create the object binaries.

Then it calls the linker, that search on those binaries for the symbols that explain what links with what. A common optimisation that linkers can do, is also strip of the final binary anything from the statically linked libraries that was not used, other common optimisation is not attempt to link at all unused libraries.

Also finally, the linker removes the things that only it needed.

What this mean in your case

You have a library, the library has the linking symbols. You also has a executable, that one had its linking symbols stripped, in fact depending on how it was optimised the internal jumps might be only a couple of jmp instructions to arbitrary addresses on the code. No machine, can do what you want in a automatic manner, because you don't have the needed information on the executable.

How to do it anyway

You need to disassemble the executable, figure on your own where are the function calls, and then manually reassemble it with your library, changing those functions call to jump to addresses in your library instead.

This process is sometimes used by game moders to change the video drivers of old games (for example to update their OpenGL version, or to force Glide games to use some newer drivers, and so on).

So if you want to do that anyway (I warn you: it is absurdly crazy to do though...) ask those guys :) I don't remember right now anyone to point to you, but they exist.

Analogy

When you are in normal linking phase, the compiled object files are like a source code that the machine understands, full of function calls as needed.

After it is compiled, all function calls became goto.

So if you are a linker tasked in doing what you want to do, imagine that you would be reading a source code filled with goto to random places in the code (sometimes even to inside loops) and that you have to somehow figure what ones of those you want to change to jump to the new part you are trying to paste there.

Burgenland