You are looking at historical revision 35472 of this page. It may differ significantly from its current revision.
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:
- Distribute source code, which requires that the target system has a compatible version of CHICKEN installed
- Distribute C files generated from Scheme source code and compile them binaries on the target system - this also requires a matching CHICKEN installation on the target
- Distribute compiled binaries, either statically linked or built in such a way that all required extensions and libraries are included in the distribution
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 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.
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 the linking model
Next: Cross development