I'm creating a framework that links against a static library using the linker flags -pagezero_size and -image_base
The library is LuaJIT compiled for 64 bits on Mac OS X, and my framework is just an ObjC wrapper for LuaJit plus a bridge to load other frameworks and passing classes and instance objects back and forth.
Everything works fine, but now I want to start writing tests for my framework before I start making some modifications, but the problem is that Xcode complains that pagezero_size is only for the main executable. i.e. adding the flags to the test target throws the error:
ld: -pagezero_size option can only be used when linking a main executable
Any ideas how to run tests for a static library that needs to be linked using -pagezero_size and -image_base?
Related
I have legacy c++ code that I'm trying to re-engineer.
I want to take some part of code out of the project as a ".so" shared library and load them dynamically by "dlopen".
I have written a dynamic loading mechanism which can load new modules dynamically at runtime.
Now I want to decouple existing modules from main project.
For instance I have extracted module "X" from the main project and created shared library which can be loaded later, but some part of the main project are using module X's classes directly and I can't change them yet.
I can compile the project by using module X's header files, but linker throw out "undefined reference" error.
How can I tell c++ linker that these classes will be added later by dlopen mechanism at runtime?
note: I can link and run project by copying created ".so" file of module X in "/lib" folder and use it when linking by "-lX" flag, but if I delete this file form the /lib folder the project fails on startup.
I know if you use X's classes directly you have to link X.so to your program. But if you link X.so you can use dlopen in runtime.
What you need is called an import library. They contain small wrappers for all necessary functions and thus satisfy all static linker dependencies. At runtime these wrappers will load dynamic library if it's not yet loaded and forward execution to real implementation inside library.
Import libraries is a standard feature of Windows DLLs but they are not available out-of-the-box on Linux (or any POSIX system). You can implement wrappers by hand or use Implib.so to generate them automatically.
I've workspace with two project: static lib and cocoa application. Static library link some system frameworks(libcrypto.dylib) and include dynamic lib's .h files(openssl/bn.h openssl/rsa.h). My static library compiles successfully.
Cocoa application uses this static library and at compile time gives an error: "undefined symbols, symbols not found" (bn, new rsa etc).
But when I include libcrypto.dylib also into cocoa application project then there is no error.
Question: Xcode can do this automatically, by taking dependency from the static link library?
Thanks.
The answer is unfortunately no. It is common practice to include each single static library in the project that requires the code. That is just the way it is done.
There is an interesting article on how to handle multiple static libraries in an XCode project.
I've build a Framework for an Objective-C App. I've tested it on minimalistic Programs where it worked. I was trying to use it in a real App now. Unfortunately the linker can't find the definition of my classes. =(
When I try to run it, I get the following Error Message:
Undefined symbols for architecture x86_64:
"_OBJC_CLASS_$_ClassInMyFramework", referenced from:
objc-class-ref in libMyLib.a(MyLib.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
The Dependency:
App -> libMyLib.a -> MyFramework.framework
The usual suggestion for this error message is to add the framework into the "Link Binary with Library" Build Phase... I can assure you that this has happened ;)
My first thought is that something might be wrong with the Build Settings which results in this linking error.
On second thought It may have to do with the Project-Setup. Is it possible to statically link a framework into an '.a' library file?
Update:
I've linked the Framework into the App and now it's working. But I don't consider this a clean solution. Help still appriciated. =)
The short answer is no, you can't link the framework statically into your .a file. See this discussion.
The reason is, the static library doesn't include the object code (the definition) of classes from the dynamic framework. The static library links to object code in the framework the same way the app links to the framework code: at run-time.
From Apple's Framework Programming Guide: "Dynamic shared libraries have characteristics that set them apart from static linked shared libraries. For static linked shared libraries, the symbols in the library are checked at link time to make sure they exist. If they don’t exist, link errors occur. With dynamic shared libraries, the binding of undefined symbols is delayed until the execution of the program."
It depends on what you want to be able to do with your code. You could add a static "target" for your framework project, so your framework project outputs both a framework and a static library. You could include this static library into apps.
But, one benefit of frameworks is that you can include nibs, images, headers, etc. So, linking your framework into your apps directly is not a bad way to go. Otherwise, you need to include these assets directly into your project. If you want this framework to be distributed with your app, you'll need to package it inside the app wrapper.
It looks like some people create a "static framework" for inclusion into an iOS project, but this looks a bit hacky to me.
As an interesting exercise, you can explore the symbols in your object code. Let's say you are using a ClassInMyFramework (from your framework) somewhere in your static library, like:
ClassInMyFramework *myFramework = [[ClassInMyFramework alloc] init];
The static library will then include the _OBJC_CLASS_$_ClassInMyFramework symbol. You can see the list of symbols in your static library file at the command line:
$ nm /path/to/libMyLib.a
This will output a list of symbols, which will show that _OBJC_CLASS_$_ClassInMyFramework is undefined (note, the "U" designates that the class is undefined):
U _OBJC_CLASS_$_ClassInMyFramework
Whereas, if you were do to the nm command on your framework:
$ nm /path/to/MyFramework.framework/Versions/A/MyFramework
Your output would show that the symbol is defined in your framework (though the definition will still only linked at run-time), which would look something like this, showing an address of the definition:
0000000000001100 S _OBJC_CLASS_$_ClassInMyFramework
I am trying to create unit tests to my project, I have workspace with several projects with tens of static libraries and apps. So, I created a new project for static library in this workspace and added Cocoa Touch UnitTest bundle to it. Then I added a test for one of the functions in one of the libraries in this workspace, lets say library X, I also added link dependency to my unit test bundle to lib X. But when I run unit tests (Cmd + U). I get linker error:
Undefined symbols for architecture i386:"_OSVersion", referencedfrom:-[MyUnitTest testMethodFromLibX] in MyUnitTestTest.o "_methodFromLibX", referenced symbol(s) not found for architecture i386
Why test bundle is not linking with library X? I can see libX.a and MyUnitTests.octet in build folder.
Ok, thanks all, I found cause of the problem - my libX was Objective-C++ library, so linker mangled all names, but my Unit-Tests were Objective-C library, so when it was linking it obviously couldn't find method or class by name, since linkage was different. So, I convert unit-tests into Objective-C++ library(just changed *.m -> *.mm) and everything works!
Unit tests run in the simulator, and so every library need to have a x386 version. You can use the command line to examine each - i believe "file lib.a" does this but a quick google search will turn up the name.
For building a static library, is the static C runtime statically linked at compile time (of the library) or at final EXE compile time?
According to Hans, the CRT (C Runtime) is not linked while compiling a static LIB using MSVC. It is linked at final EXE compile time.
However, even though this is true. You still cannot mix C runtimes in static libraries. They all must use the same exact runtime (or the system runtime MSVCRT.dll)