skalibs
Software
www.skarnet.org

How to cross-compile skalibs

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

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

Support for parallel builds

Let's assume that:

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

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

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:

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:

  1. finding the target's (i.e. here the build arch's) systype
  2. building correct compilation scripts from the systype and the information you gave in conf-compile
  3. making some build-time tests to gather sysdeps, i.e. arch-specific information, used in the sources to work around possible portability problems
  4. 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.