The cc and c++ compilers included in Apple's command line tools show some
unusual behaviour which causes the build to fail in several projects under
Xcode 4.3
This patch uses the gnu compatibility gcc and g++ compilers on OS X instead
to reduce problems, and generates an error when an llvm based compiler is
detected because they currently do not generate usable emulator executables
due to them not honouring global register variables.
Change-Id: I506c22dad3dcbd41df3c7672802a675d3655e262
Signed-off-by: Al Sutton <al@funkyandroid.com>
Enable relro / bind_now when compiling Android applications.
This marks certain regions of memory as read-only after linking,
making memory corruption security vulnerabilities are harder
to exploit.
See:
* http://www.akkadia.org/drepper/nonselsec.pdf (section 6)
* http://tk-blog.blogspot.com/2009/02/relro-not-so-well-known-memory.html
Stop using the custom linker script, which inhibits
relro / bind_now support.
Change-Id: Ie97ccdd2845886bbc2ba2fdd47eed0ff4b29b60b
Enable relro / bind_now when compiling Android applications.
This marks certain regions of memory as read-only after linking,
making memory corruption security vulnerabilities are harder
to exploit.
See:
* http://www.akkadia.org/drepper/nonselsec.pdf (section 6)
* http://tk-blog.blogspot.com/2009/02/relro-not-so-well-known-memory.html
Stop using the custom linker script, which inhibits
relro / bind_now support.
Change-Id: Iaebfbbb492299004f9da92b649985b6cd67d8c97
By default we build tool in 32-bit. This flag allow individual tool and its
dependencies to be built in 64-bit (eg. Emulator). Fixes to resolve 64-bit
porting issues (in other git) will be submitted seperately.
Change-Id: I486cf7ddac727d3c374ed890857d497c3a69e598
Everything that is based on ARMv7a should have a cp15 TLS register.
Enable it by default so it's not accidentally missed in newer board
configurations. In fact, this could be enabled for ARMv6 as well, but we
currently don't distinguish between ARMv5 and ARMv6 in the build system.
This can still be disabled by setting it to "false" in the board
configuration, but this shouldn't ever be needed.
Change-Id: Ic2918f32899c8bcfa482f92c98f5a192fa318470
With "-Wl,-rpath,@loader_path/../lib" the linker embeds
@loader_path/../lib as the target binary's rpath.
Here @loader_path means the path of the binary that initiates the
loading.
With "-install_name @rpath/libfoo.dylib " the linker runtime searches
libfoo.dylib in the binary's embeded rpath.
With this change you can call dlopen() without specifying the full path
of the shared library.
Change-Id: If9beb3f6f4642a377bff603bab5ba3fdb96211bf
Before this change, path of the install name is relative to the top dir.
That means you can execute dynamically-linked binaries only in the top dir.
With this change, you can execute dynamically-linked binaries anywhere.
Change-Id: I1c6441579ffb68505ea678296aceb2e66a6df1be
So we can have the same set of module names in different host arch
/ toolchain version combinations.
Change-Id: Iec66584bf3de92aedd71a59f9dbe74b6ed025b2e
This is the result of a recent conversation around the x86 ABI
and its relationship with how we build platform images. Briefly:
- We want to use feature-based macros like ARCH_X86_HAVE_$FEATURE
instead of relying on explicit compiler macros like -DUSE_$FEATURE
- We want to allow for other x86-based arch variants, e.g. if
someone wants to build Android for a CPU that doesn't support
the NDK x86 ABI. However, we need to ensure these are not
tagged compatible by mistake (see check at the end of TARGET_linux-x86.mk)
- There are several flags which use is dubious now that we have
a dedicated toolchain to build all the x86 stuff. Comment them
as 'to be considered for removal'. We'll do the proper checks
later.
Change-Id: I7768d7c34d73e274cbf4c09ae831b55280d6bb58
While building Android with latest host gcc, it causes the following
build error:
Install: out/host/linux-x86/bin/mkbootimg
host C++: obbtool <= frameworks/base/tools/obbtool/Main.cpp
<command-line>:0:0: error: "_FORTIFY_SOURCE" redefined [-Werror]
<built-in>:0:0: note: this is the location of the previous definition
cc1plus: all warnings being treated as errors
In order to make build system happy, this patch does unset macro
_FORTIFY_SOURCE and then define it in host cflags.
Change-Id: Ic37a90f05081a2c3650b3335bc87e9e895900fb2
Compile all x86 programs on Android with -fPIE and -pie. This enables
PIE (Position Independent Executables), which helps protect Android
applications from exploitation due to memory management bugs.
Note 1: PIE *static* executables are not supported at this time and
require additional linker changes.
Note 2: This change compliments 026a85b129,
which was the exact same change, except for ARM.
Testing: Rebuilt the tree completely from scratch, and verified
that the system boots and basic functionality works in the emulator.
Change-Id: I990064c37da3d857e663b27f31fee05f689a2824
Compile all programs on Android with -fPIE and -pie. This enables
PIE (Position Independent Executables), which helps protect Android
applications from exploitation due to memory management bugs.
Stop using the armelf.x linker script. This script hard codes the
load address of the executable, defeating the position independence
PIE requires.
Note: PIE *static* executables are not supported at this time and
require additional linker changes.
Bug: 5323301
Change-Id: Ieafcc9c4f142495847e163881889d371a59d0878
While building Android with latest host gcc, it causes the following
build error:
Install: out/host/linux-x86/bin/mkbootimg
host C++: obbtool <= frameworks/base/tools/obbtool/Main.cpp
<command-line>:0:0: error: "_FORTIFY_SOURCE" redefined [-Werror]
<built-in>:0:0: note: this is the location of the previous definition
cc1plus: all warnings being treated as errors
In order to make build system happy, this patch does unset macro
_FORTIFY_SOURCE and then define it in host cflags.
Change-Id: Ic37a90f05081a2c3650b3335bc87e9e895900fb2
