This is necessary to ensure that dlclose() will properly call C++
destructors for the static objects within the shared library.
Change-Id: Ieb056042f9cda7ab120eb770b21f365cd6d64a66
gcc-4.4.3 toolchain is based on fsf GCC-4.4.3 with numerous patches.
It reduces 3.65% code size than the prebuilt gcc-4.4.0 toolchain,
and improves 3.4% performance on Android benchmarks.
The toolchain uses gold as default linker. With gold, the toolchain
further reduces 1MB system image.
Change-Id: I55eb4df185f2932e71498fcc28428e4d1b175393
Merge commit 'b6bee6f17187a9eb3645e9519cca4a126d9aca21'
* commit 'b6bee6f17187a9eb3645e9519cca4a126d9aca21':
Remove irritating warnings about 'va_list' mangling when building C++ sources.
Security hardening: don't allow code to compile which
uses format strings in an inappropriate way. Make format
string compiler warnings into errors.
Change-Id: I1461dad589a2416420fd84ccf765983e859eea8a
Add -Wa,--noexecstack and -Wl,-z,noexecstack as default
flags when compiling applications. This enables NX
protections, which prevent code from executing on the
stack or heap. NX protections can block a large number
of buffer overflow attacks, and is an important security
feature.
Change-Id: Iad4bab9f8664584ba6ce832a5318d07680d7a908
A package can define a LOCAL_LDFLAGS. If a LOCAL_LDFLAGS
exists, it should come after the global LDFLAGS, to allow
the local flags to override the global flags.
Change-Id: I6e44c17949c1f11c808d0ed3f327d63fb51a1468
This adds "-lpthread" to TARGET_GLOBAL_LDFLAGS when TARGET_SIMULATOR
is true. This is much easier than inserting it into individual
makefiles as needed. Has no effect on other builds.
Should fix the sim-eng build breakage in libcameraservice.
Change-Id: I4dcd7d54b93d1be1622b8ce78a1662d28ca9f9f2
This detail got lost in my previous cleanup change 9b4a812.
Also add a comment explaining why the host side of the
simulator needs to be built in 64-bit (wxWidgets).
Change-Id: I2a867f7f80b43d53e73348b19f6ae834600295f9
The only OS-ARCH combo that would have benefited from it
is linux-x86, but it explicitly used separate configurations
for the HOST_ and TARGET_ side of things.
This makes is clear which files are related to the HOST_
configuration and which ones are related to the TARGET_
configuration, and expands $(combo_target) to the only
possible/reasonable value that it could have had in every
file.
This also cleans up the simulator, by moving it in a single
place in TARGET_linux_x86 (since the only part that's special
is to use HOST_ settings even when building TARGET_ modules).
Change-Id: I2420eeb8cfe539f5807ec99cb3177ffb9f2476d5
The "set default variant to armv5te if none defined" in the ARM config
was applying to all architectures, but as it turns out only ARM builds
actually cared. When I made a copy of the "set default" code to the x86
config, one or the other would win for builds that didn't specify a
variant. Turns out x86 won, so sim and voles worked, but opal didn't.
Merge commit 'ebed06a259eb1c00112a4e3a9d6d721700bbaedb'
* commit 'ebed06a259eb1c00112a4e3a9d6d721700bbaedb':
remove reference to SK_RELEASE, since that is automatically set based on NDEBUG (or its absence)
Merge commit '65a731b737bd6e8afa0b18176064dcc130dbb4ce' into eclair-mr2-plus-aosp
* commit '65a731b737bd6e8afa0b18176064dcc130dbb4ce':
remove reference to SK_RELEASE, since that is automatically set based on NDEBUG (or its absence)
The build servers have GNU coreutils 5.93, where stat does not output
a newline. Ubuntu hardy has GNU coreutils 6.10, where it does.
Lacking a newline messes up the summing of the sizes. Fix
get-file-size to remove the newline if present, and make the total
calculation in assert-max-file-size more robust.
Also, if the image was too big, it was not actually making the build
fail (because /bin/false was not the last thing called). Fix that so
it does.
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.
This is currently a copy & paste of the armv5te parameters. I don't
know if there's a better way to encode this, or to what extent we will
need to specialize it vs. armv5te in a future build (e.g. to enable fp
instruction use in code gen).
Currently the only effect is to select the VFP-enabled mterp sources in
Dalvik.
armv4 was only implemented on StrongArm and Arm8 (See http://en.wikipedia.org/wiki/ARM_architecture)
and will be more difficult to support since it does not support the bx instruction.
armv4t on the other hand is used in a wide range of cpu:s.
armv4 is also not supported by bionic or dalvik, but armv4t is.
Thumb-mode is not yet enabled since there are some unresolved abi-issues.
architecture versions other than ARMv5TE.
The general approach is to provide TARGET_ARCH_VERSION, to complement
TARGET_ARCH. This defaults to the current armv5te. The variable
values should match the architectures as defined by gcc.
There is a block of defines for each supported architecture version
(currently ARMv5TE and ARMv4). Each block defines a set of features
using ARCH_ARM_HAVE_<x> variables. It also specifies a set of c
preprocessor defines to pass to the compiler. Finally it defines a
default CPU. (As for architecture versions, the default CPU should
match a CPU that gcc knows about.)
Support is added for architectures that do not support THUMB. Specifically
we change the 'thumb compile' target to simply compile as ARM code
instead, and we change the interworking flag passed to the compiler.
Finally, we ensure that the system/core/include/arch/linux-arm directory
is added to the default include path, which allows the use of asm/macros.h
header file described in review #1626. The way in which this done is
considerably unclean/hacky, if someone can suggest a better way please
let me know.