I don't understand what the "universal" byte order thing tries to
say. Sure, Apple's compilers can produce fat binaries, i.e. containing
code for multiple architectures, which I guess might have differing
byte order. But I think the test for an -arch flag being present here
is backwards, surely if you specify -arch i386 for instance, then we
*know* that the byte order is little endian, not "universal".
Anyway, this broke ICU when built against MacOSX SDK 10.6 at least,
the ICU configury used wrong suffix for ICUDATA_NAME, and genbrk
failed in i18npool with a mysterious "can not initialize ICU. status
= U_FILE_ACCESS_ERROR" message.
In the spirit of 12759f67a3, change
external lib's config.sub to eat the arm-unknown-linux-androideabi
host os string. Also, permit shared libs again - seems Android can
handle those.
Added dictionaries to cross-build-toolset - idxdict is needed.
Should build up to sfx2 - some residual static lib issues there,
and in raptor.
Its alternative values as used by OOo is irrelevant to us as we don't
intend to support building using MinGW on Windows itself. To us, MinGW
always means cross-compilation. For us it is enough to look at
$(OS)$(COM), and WNTGCC always implies cross-compilation.
(OOo on the other hand attempts to support use of the Cygwin gcc with
the -mno-cygwin option (which is practically considered an obsolete
option), the normal MinGW compiler (but still from Cygwin), but not
cros-compilation.)
Recognize the arm-linux-androideabi "triplet". (Actually I doubt that
is a well-formed triplet at all, what are the Google people smoking?)
Allow longer lines in pkgdata.cpp as the compiler command line gets
quite long for cross-compilation to Android.
Add the proper assembly source file format for Android to pkg_genc.c
and use that.
Probably a good idea to use --disable-dyload on Android (and iOS).
Tweak gcc flags used for Android a bit to work around some Android C
header weirdness related to strictness and 64-bit types.
Don't use the /machine:i386 switch. The defaults work fine: the 32-bit
linker will produce i386 executables, the 64-bit linker will produce
x64 ones.
Don't use the /Op compiler switch, it doesn't exist in MSVC 2008.
