There are three issues in the world of cross-compilation:
skalibs does not support out-of-tree builds at the moment, but since the source code tree is small, it's not costly to duplicate it to perform parallel builds. If the source code tree grows significantly larger, out-of-tree build support will be considered.
skalibs now uses a standard ./configure && make && make install process, and cross-compiling build-time options can be given on the ./configure command line.
This is the hardest part of cross-compilation, and very few build systems get it right. (GNU autotools does not, which is one of the reasons why skarnet.org packages do not use autotools.)
Native build procedures usually perform build-time tests: they compile executables and run them (on the build platform, which is the same as the target platform) to check for features and system quirks. skalibs does exactly that: the ./configure step performs tests on the build platform and stores the system-dependent results in a directory that it calls the sysdeps for this platform.
But in a cross-compilation environment, build-time tests are invalid, since the build platform and the target platform differ. 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, via the --with-sysdeps option to configure.
The easiest way to get the correct sysdeps for a target achitecture is to natively run skalibs' ./configure script on that target, and steal the produced sysdeps files, which are normally written to the ./sysdeps.cfg directory. Doing this is easy with a virtual machine, qemu for instance. You could also (politely) ask for precompiled sysdeps on the skaware mailing-list, if you cannot find them anywhere on the Internet.
Dan Kegel brought up the need for a clean cross-compilation system.