chickadee » chicken » deployment

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.

There are several options for distributing software written in CHICKEN for use on other machines or by other people:

The rest of this chapter addresses the third option, for which several options exist, depending on your needs and how self-contained you want your deployed binary to be.

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

 % csc myprogram.scm
 % ldd myprogram               # on linux
           linux-gate.so.1 =>  (0xb805c000)
           libchicken.so.9 => /home/felix/chicken/core/lib/libchicken.so.9 (0xb7c22000)
           libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7bec000)
           libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7be7000)
           libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7a84000)
           /lib/ld-linux.so.2 (0xb805d000)
 % ls -l myprogram
 -rwxr-xr-x 1 felix felix   34839 2010-02-22 20:19 x

Static linking

Linking your application statically will include the runtime library in the executable:

 % csc -static myprogram.scm
 % ldd myprogram
           linux-gate.so.1 =>  (0xb805c000)
           libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7bec000)
           libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7be7000)
           libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7a84000)
           /lib/ld-linux.so.2 (0xb805d000)

Extensions are transparently linked in statically, if you provide the -static option to csc, provided the extension is avaiable as a static object file (this applies to most extensions by default).

Shipping the runtime library

An alternate way of distributing compiled code is to ship the runtime library libchicken.so together with the executable, possibly including any extensions that you use. To make this work, any runtime linker paths compiled into binary objects need to be deleted or changed by using a tool like chrpath(1) or patchelf(1), to a value that indicates that the library lookup should start in the same location as the main program. (e.g. $ORIGIN on Linux). Don't forget to copy any extensions from the extension repository ($PREFIX/lib/chicken/$BINARYVERSION).

Alternatively start your program through a separate script that sets LD_LIBRARY_PATH (or DYLD_LIBRARY_PATH on MacOS X). For more details, consult the documentation of the operating system that you use to build your deployed binaries.

A directory containing all binaries 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 track them down yourself and place them in the application directory.

Distributing compiled C files

It is possible to create distributions of Scheme projects that have been compiled to C. The runtime system of CHICKEN consists of only two handcoded C files (runtime.c and chicken.h), plus the files chicken-config.h and buildtag.h, which are generated by the build process. All other modules of the runtime system and the extension libraries are just compiled Scheme code. The following example shows a minimal application, which should run without changes on most operating systems, like Windows, Linux or FreeBSD (note however that static binaries are not supported on Mac OS X).

Take the following "Hello World" program:

; hello.scm

(print "Hello, world!")
 % csc -t hello.scm -optimize-level 3 -output-file hello.c

Compiled to C, we get hello.c. We need the files chicken.h, chicken-config.h, buildtag.h and runtime.c, which contain the basic runtime system, plus the library files build-version.c, chicken-syntax.c, eval.c, expand.c, internal.c, library.c and modules.c, which contain the same functionality as the library that is linked into plain CHICKEN-compiled applications:

 % cd /tmp
 % echo '(print "Hello World.")' > hello.scm
 % csc -t hello.scm
 % cp $CHICKEN_BUILD/build-version.c .
 % cp $CHICKEN_BUILD/chicken-syntax.c .
 % cp $CHICKEN_BUILD/eval.c .
 % cp $CHICKEN_BUILD/expand.c .
 % cp $CHICKEN_BUILD/internal.c .
 % cp $CHICKEN_BUILD/library.c .
 % cp $CHICKEN_BUILD/modules.c .
 % cp $CHICKEN_BUILD/runtime.c .
 % cp $CHICKEN_BUILD/chicken.h .
 % cp $CHICKEN_BUILD/chicken-config.h .
 % cp $CHICKEN_BUILD/buildtag.h .
 % gcc -Os -fomit-frame-pointer -DHAVE_CHICKEN_CONFIG_H hello.c \
   build-version.c chicken-syntax.c eval.c expand.c internal.c \
   library.c modules.c runtime.c \
   -o hello -lm

Once we have all the files together, we can create a tarball:

% tar czf hello.tar.gz hello.c build-version.c chicken-syntax.c eval.c \
  expand.c internal.c library.c modules.c runtime.c chicken.h \
  chicken-config.h buildtag.h

This is naturally rather simplistic. Things like enabling dynamic loading and selecting supported features of the host system would need more configuration- and build-time support. All this can be addressed using more elaborate build-scripts, makefiles or by using autoconf/automake.

The chicken-config.h file may contain incorrect settings for your deployment target. Especially when the architecture is different. In that case you will have to adjust the values as needed.

For more information, study the CHICKEN source code and/or ask on the CHICKEN mailing lists to understand the implications and difficulties of this deployment method in more detail.

Platform specific notes

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

The otool(1) program will show you dynamic libraries that your application requires. DYLD_LIBRARY_PATH can be set to override runtime linker paths and install_name_tool(1) is available to patch runtime linker paths directly. All of these tools require the Xcode command-line tools too be installed.


Previous: Units and linking model

Next: Cross development