so that on version bumps and/or added/removed patches that we
rebuild them from scratch, which hopefully will make incremental
builds post external module bump pain-free
Change-Id: If268401a2794989d49861c08f7a69ef926cf5809
my mips supports hash-style=both, but if you actually use it ld
barfs with "gnu.hash is incompatible with the mips abi"
everywhere else we just do -Wl,--hash-style=$(WITH_LINKER_HASH_STYLE)
Change-Id: Ie310b7edad0d3068e5c4fcfed22aaea96698a06b
We might eventually want to use Mike Hommey's "faulty.lib" dynamic
linker (developed for Firefox on Android) to get around the Android
system dynamic linker's silly limitations. It does not like
DT_RPATH. (The Android system dynamic linker just ignores those.) So
no point putting RPATH into the ICU libs for Android.
Note that the faulty.lib linker is not usable currently because it
doesn't like the text relocations that the NDK r8 toolchain generates
for some reason. Sigh.
Change-Id: I9092c6001f0aadbb30e2682e33e7179520846f3b
...by allowing our special @___... tokens anywhere within an install name,
so that external modules can configure --prefix=/@___... etc. This removes
the need for the special extshl and EXTRPATH=LOADER. Also, a new
OUT2BIN_NONE can be used for external modules where the generated libraries
need the default EXTRPATH=OOO, but generated executables are only used
during the build and such need RPATH=NONE.
But... the names our ICU libraries get built as clash exactly with
Android's system ICU library names, predictably leading to chaos. I
will have to come up with a non-clashing names for our ICU libraries
on Android.
(But isn't it stupid to include an own build of ICU if there is one in
the system already? Sure, but on the other hand the NDK doesn't
include ICU headers or libraries, so clearly Google doesn't consider
it part of the documented API. No guarantee of version stability
etc. Indeed best to avoid them then.)
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.
