This is a userspace compatibility layer for running Darwin/OS X binaries on Linux.

General information

For more information (such as build instructions), visit http://www.darlinghq.org

Hacking tutorial

Want to help? Visit the developer zone at http://www.darlinghq.org/developer-zone

Directory tree

benchmarks/

No serious stuff in here, used only once for a simple ObjC msg sending benchmark.

etc/

Contains dylib.conf which is used to map OS X library (framework) paths to Linux/Darling ones. `/dev/null` = load nothing.

include/

Header files taken from Darwin/OS X (APSL license). The plan is to get rid of these eventually.

misc/

Random files, nothing that really matters.

src/

Source code, see below.

tests/

Test runner. It is specifically designed to work on my testing setup. See below.

tests/src/

The source code for tests.

tools/

Various utilities used during the development.

Source tree

The structure under src/.

src/libSystem/

Wrappers or implementation of libc funcions, BSD system calls and Mach system calls.

src/libobjcdarwin/

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.

src/util/

Various utility functions/classes common to all parts of Darling.

src/libmach-o/

Mach-O parsing/loading library.

src/dyld/

The dynamic loader.

src/motool/

A very simple tool for Mach-O file examination. (An allusion to "otool" available on OS X.)

src/crash/

A crash ("force quit") dialog app for Cocoa apps. Not really complete yet.

...

The rest is code or wrappers in various stages of completion.

Tests tree

The testing procedure implemented in src/tests/runtest.cpp is as follows:

1. It copies the source file to the OS X machine.
2. It remotely builds the source file. If the current binary name is runtest32, then -m32 is added and dyld32 is used later on. A similar runtest64 symlink 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.
3. It remotely runs the program and keeps its stdout.
4. It copies the binary over to the local machine.
5. It runs the binary via dyld/dyld32/dyld64.
6. It compares the stdout contents of dyld with that of the remotely run binary.
7. Should the stdout contents differ or should the process exit with a non-zero code on either of the systems, the test has failed.

Debugging

Find out how Darling can help you with debugging at http://www.darlinghq.org/for-developers/debugging-in-darling

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.