How to cross-compile skalibs

There are three issues in the world of cross-compilation:

support for parallel builds: the source directory must be read-only and each build process must have its own build tree.
support for compiler options: to specify the target architecture, the header and library files that should be used, etc.
build-time tests performed on the build architecture are invalid if the target architecture is different.

Starting with release 0.26, skalibs tries to address those issues.

Support for parallel builds

Let's assume that:

You untarred the skalibs-$VERSION.tar.gz archive into $BUILDROOT.
You made a symlink $BUILDROOT/prog/skalibs -> skalibs-$VERSION. (This is not really necessary, but it allows you to access the skalibs source tree as $BUILDROOT/prog/skalibs no matter the version number.)

You now have 5 subdirectories in the $BUILDROOT/prog/skalibs directory:

conf-compile. This is where you will write compilation options.
doc. The skalibs documentation you are currently reading. Not used in the build process.
package. Build system scripts and general package information. You should not modify anything there unless you know exactly what you are doing.
src. The source tree.
precompiled-sysdeps. Some sets of precompiled sysdeps; more on that below.

None of those directories are written into by the skalibs build system. Instead, the build scripts create the following directories:

compile. This is where all the compilation takes place. Every source file will be symlinked there, and object files will be created there.
include. This is where the target header files will reside after the compilation.
library. This is where the target library files will reside after the compilation.
sysdeps. This is where the target system-specific information will reside after build-time autodetection or manual importing. More on that below.

To prepare for a build in a separate place - say, in $ARCHROOT/skalibs - that will not modify the directory where the sources have been unpacked, so that parallel builds can occur, you should then take the following steps:

mkdir $ARCHROOT/skalibs
symlink the $BUILDROOT/prog/skalibs/package and $BUILDROOT/prog/skalibs/src directory into $ARCHROOT/skalibs
mkdir $ARCHROOT/skalibs/conf-compile

You now have your own arch-specific $ARCHROOT/skalibs tree; it's time to fill it with arch-specific options.

Support for build-time options

The first line of conf-compile/conf-cc must be the command line used to compile a .c file into a .o file: for instance, gcc -c.
If you're using a "GNU configure"-type system with $CC and $CFLAGS, the following line should be enough:

  echo ${CC} ${CFLAGS} > conf-compile/conf-cc

Similarly, the first line of conf-compile/conf-ld must be the command line used to link .o and .a files into an executable: for instance, gcc -s.
With a "GNU configure"-type system, the following line should do the trick:

  echo ${CC} ${LDFLAGS} > conf-compile/conf-ld

Now, there is another file: conf-compile/conf-egd. If you're going to perform build-time autodetection, you need to provide it now:

  echo path-to-the-target-EGD-socket > conf-compile/conf-egd

or, if you won't be using EGD, just

  echo > conf-compile/conf-egd

But you probably do not need to do that, because you will be providing your own sysdeps.

Starting with 0.27: there are two other files, conf-stripbins and conf-striplibs. Since skalibs does not provide any executables, and since you are cross-compiling, avoid trouble and do not strip anything:

  echo > conf-compile/conf-stripbins
  echo > conf-compile/conf-striplibs

Bypassing the build-time tests

The "normal" skalibs build procedure, package/compile, performs the following steps:

finding the target's (i.e. here the build arch's) systype
building correct compilation scripts from the systype and the information you gave in conf-compile
making some build-time tests to gather sysdeps, i.e. arch-specific information, used in the sources to work around possible portability problems
compiling the portable sources.

In a cross-compilation environment, the steps 1 and 3 are clearly invalid: the autodetected systype and sysdeps will be the build architecture's, not the target architecture's. There is only one way to cross-compile portable code without resorting to build-time autodetection: you must provide by hand the sysdeps for your target architecture.

The easiest way to get the "right" sysdeps for a target achitecture is to natively compile skalibs on that target, and steal the produced sysdeps files. The skalibs package comes with a small set of predefined sysdeps files that I got that way; your target may be more or less accurately represented by one of the subdirectories of precompiled-sysdeps.

The most powerful way to get the sysdeps would be to have a program such as GNU autoconf automatically generate them at build-time. I won't convert skalibs to autoconf, but contributions such as autoconf-to-sysdeps scripts are welcome.

Dan Kegel has kindly provided some step-by-step notes on making sysdeps files for your target architecture.

So, one way or the other, you have filled up conf-compile, and you have a predefined set of sysdeps in $SYSDEPSDIR, for instance $BUILDROOT/prog/skalibs/precompiled-sysdeps/i686-openbsd-3.2.
Instead of performing package/install for a native installation, or package/compile for a native compilation without the install phase, you just perform

  package/crosscompile ${SYSDEPSDIR}

The set of sysdeps in $SYSDEPSDIR will be imported into the build tree, and the portable sources will be compiled. The header files will be produced in the include directory, and the library files in the library directory. That's it.

Credits

Dan Kegel brought up the need for a clean cross-compilation system.