I have started an Android port, I am using android-cmake which seems to allow VXL to build for the most part with the proper arm architecture switches straight out of the box.

I have run into four problems so far, solving two of them and the remaining two are unsolved.

Firstly, as you are building for a remote platform is not clear to your build architecture what the endian type is.  I have added the following lines to the root level CMakeLists.txt around line 33

OPTION(VXL_CHECK_ENDIAN "Check for target platform endian type?" YES)
OPTION(VXL_IS_BIG_ENDIAN "Whether the target platform endian type is big?" YES)

The idea here is that if you know the endian type of the remote platform you can just set it as a cmake option, the naming of these variable may not be ideal...

Secondly the file search.h does not exist in the Android NDK consequently there are problems when building tiff support. Due to this the following edits are made to v3p/tiff/tif_config.h

/* Define to 1 if you have the <search.h> header file. */
#ifndef ANDROID
#define HAVE_SEARCH_H 1
#endif // ANDROID

There are two further problems that I have hit that I have not been able to get around yet mostly because they will require some changes to vcl and more specifically the support of std C functions within.  There is an absence of snprintf (from vul_url) and the function __errno_location (vil_nitf2_typed_field_formatter.cxx) for the Android platform.

A fix to the snprintf would be to provide this definition somewhere :
snprintf(char *str, size_t n, const char *fmt, ...)
  va_list ap;
	int ret;
	char dummy;
	FILE f;
	struct __sfileext fext;

	/* While snprintf(3) specifies size_t stdio uses an int internally */
	if (n > INT_MAX)
		n = INT_MAX;
	/* Stdio internals do not deal correctly with zero length buffer */
	if (n == 0) {
		str = &dummy;
		n = 1;
	_FILEEXT_SETUP(&f, &fext);
	f._file = -1;
	f._flags = __SWR | __SSTR;
	f._bf._base = f._p = (unsigned char *)str;
	f._bf._size = f._w = n - 1;
	va_start(ap, fmt);
	ret = vfprintf(&f, fmt, ap);
	*f._p = '\0';
	return (ret);

Another issue I have read about is the packing of bytes in structs

struct {
unsigned char something;
int else

Would result in a sizeof() = 8 not 5 on a typical system, I don't know if this is problematic or not.

As far as I can tell these are the only issues in the core libraries and I suspect that there are probably some straight forward solutions for those of you that understand vcl adequately.

Does anyone have some ideas about solutions?  Or is there any general interest in adding in these support fixes to the SVN?

David McKinnon...