Deployment

CHICKEN generates fully native binaries that can be distributed like normal C/C++ programs. There are various methods of deployment, depending on platform, linkage, external dependencies and whether the application should be built from sources or precompiled and whether the CHICKEN runtime-libraries are expected on the destination system or if the application should be completely self-contained.

Simple executables

The simplest form of deployment is the single executable. The runtime library (libchicken.so or libchicken.dll) is required for these programs to run, unless you link your application statically:

Programs distributed this way can only use Extensions if these extensions get linked in statically, which is basically supported but not available for all extensions.

Self contained applications

The solution to many of these problems is creating an application directory that contains the executable, the runtime libraries, extensions and additional support files needed by the program. The executable has to be linked specially to make sure the correct included runtime library is used. You do this by using the -deploy options provided by the compiler driver, csc:

There is one restriction that you should be aware of: you cannot chicken-install -deploy an uninstalled extension, e.g. directly from an SVN checkout. You must first install it on your build system normally with chicken-install, so that csc can find its import library in the system-wide repository (or in a custom one if you have set CHICKEN_REPOSITORY). This is only needed while you are deploying the extension into the application directory; once deployed, of course, it's totally self-contained.

You can execute the program from its location, or you can install a symbolic link pointing to it - it will find the correct directory where the actual executable is located.

The application directory is fully "portable" in the sense that it will run directly from an USB-stick or any other removable media. At runtime the program can find out its location by invoking the repository-path procedure, which will return the full pathname in which the application is located.

Should the program depend on more libraries which are not available by default on the intended target systems, and which you would like to include in your application, you will have to hunt them down yourself and place them in the application directory. If these again have dependencies, things will get complicated and will involve things like patching binaries or writing "trampoline" shell scripts to run your application.

Platform-specific notes

Linux

Deployment is fully supported on Linux

Windows

Deployment is fully supported on Windows. Since Windows looks up dynamic link libraries in the programs original location by default, adding third-party libraries to the application directory is no problem. The freely available Dependency Walker tool is helpful to find out what DLLs your application depends on.

MacOS X

On the Macintosh, passing the -gui option to csc will result in a true GUI application bundle (named <your-program>.app).

Invoking

% otool -L <yourprogram>

will list dynamic libraries that your application needs.

Other UNIX flavors

Setting up the application executable to load runtime libraries from the same directory is supported on FreeBSD, OpenBSD and Solaris. NetBSD supports this from version 5.0 onwards - this is currently disabled in csc for this particular platform.

Deploying source code

An alternative to deploying binaries is deployment as compiled C sources. Usually, you just need to ship your application code, compiled to .c files and the chicken.h and runtime.c files from the CHICKEN sources. You will also need the .c files of any library units your program uses (at least library.c and build-version.c). Compiling everything and linking it together should work on most systems. Consult the CHICKEN makefiles for more information about optimization options, etc.