This is a userspace compatibility layer for running Darwin/OS X binaries on Linux.
For more information (such as build instructions), visit http://darling.dolezel.info
Want to help and don't know what's currently important? Let me know! Google Group: https://groups.google.com/d/forum/darling-project
Important: Use git clone -r (as in recursive) to check out this project.
- No serious stuff in here, used only once for a simple ObjC msg sending benchmark.
- Contains dylib.conf which is used to map OS X library (framework) paths to Linux/Darling ones. `/dev/null` = load nothing.
- Header files taken from Darwin/OS X (APSL license). The plan is to get rid of these eventually.
- Random files, nothing that really matters.
- Source code, see below.
- Test runner. It is specifically designed to work on my testing setup. See below.
- The source code for tests.
- Various utilities used during the development.
The structure under
- Wrappers or implementation of libc funcions, BSD system calls and Mach system calls.
- Loader of ObjC classes/protocols in Mach-O ObjC applications. Contains code for selector fixups and other techniques needed to "make it work" with GNUstep's libobjc2.
- Various utility functions/classes common to all parts of Darling.
- Mach-O parsing/loading library.
- The dynamic loader.
- A very simple tool for Mach-O file examination. (An allusion to "otool" available on OS X.)
- A crash ("force quit") dialog app for Cocoa apps. Not really complete yet.
- The rest is code or wrappers in various stages of completion.
The testing procedure implemented in
src/tests/runtest.cpp is as follows:
- It copies the source file to the OS X machine.
- It remotely builds the source file. If the current binary name is
-m32is added and
dyld32is used later on. A similar
runtest64symlink is needed if your 64-bit dyld is called
dyld64. If the first line in the source file is
// CFLAGS:, then the rest is used as CFLAGS.
- It remotely runs the program and keeps its stdout.
- It copies the binary over to the local machine.
- It runs the binary via dyld/dyld32/dyld64.
- It compares the stdout contents of dyld with that of the remotely run binary.
- Should the stdout contents differ or should the process exit with a non-zero code on either of the systems, the test has failed.
src/tests/libsshcxx, a copy of my libssh C++ wrapper should check itself out.
Find out how Darling can help you with debugging at http://darling.dolezel.info/en/Debugging
What NOT to do
To avoid mistakes:
- DO NOT use opencflite and similar Apple CFLite forks, unless you know what you're doing. They lack bridging support with gnustep-base. Bridging between gnustep-corebase and -base is at least work in progress. Should CFLite forks ever fix a bug for you, please help fix the problem in gnustep-corebase.