BoardConfig.mk typically defines TARGET_CPU_ABI to the name of the
native machine code CPU ABI supported by the target device. For example,
existing devices today use the value 'armeabi' corresponding to an
ARMv5TE instruction set with soft-float implementation.
This patch allows this file to also define TARGET_CPU_ABI2 to name
a secondary (minor) CPU ABI also supported by the device. This is useful
when the main ABI is ARMv7-A (identified as 'armeabi-v7a') which also
supports ARMv5TE. Such devices should have TARGET_CPU_ABI defined to
'armeabi-v7a' and TARGET_CPU_ABI2 defined to 'armeabi'.
TARGET_CPU_ABI2 will be translated into the ro.product.cpu.abi2 property
in build.prop. This value will be used by the PackageManager to handle
"fat-binaries" generated with the NDK.
to make not having a virtual destructor in classes with virtual
methods an error. I already fixed all code that had this problem,
so now it's a matter of turning the option on.
Also, as long as we don't have any C-specific options, it's
probably best to copy the CPP flags from the C flags. We can
always break them out later.
Merge commit 'e41accf68eedfd17bc569aee8480cf8c48d82e61'
* commit 'e41accf68eedfd17bc569aee8480cf8c48d82e61':
Pass compiler flags for C++ too, and add a flag that enables warnings about missing virtual destructors
This allows TARGET_ARCH_VARIANT to be set by the vendor before we choose the
architecture in core/combo/select.mk.
Also add a primitive armv7-a.mk for turning on hardware floating point.
Use zlib's minigzip utility, built as part of our source tree, instead of
whatever installation of GNU gzip happens to be on the user's machine.
Using zlib's deflater, which is nicely available as a library (unlike
GNU gzip's deflater) will ultimately let us do binary patches to the
boot and recovery images.
