The compiler run-time library should always be the _last_ thing linked
when building static executables. This was being done correctly for
libgcc, but not when using compiler-rt.
Change-Id: I0689dc35f55caad2fe74c0cbb4cbe3008ded349a
To enable building with coverage, the environment variable
NATIVE_COVERAGE must be set to true.
Set `LOCAL_NATIVE_COVERAGE := true` to generate coverage information for
a given component.
This is currently not supported for clang (b/17574078, b/17583330).
If static library A is included in a binary B (dynamic or static
executable, or shared library), and A is built with coverage
information, B is required to link with libgcov.a. Since the make does
not offer a good way to track this dependency, link libgcov.a even if
LOCAL_NATIVE_COVERAGE is not set (but still guarded by NATIVE_COVERAGE).
This ensures that all of the libgcov dependencies will always be
resolved, and causes no change in the resulting binary if coverage is
not used.
Bug: 10134489
Change-Id: Id5a19f2c215e4be80e6eae27ecc19b582f2f6813
Preparing for migration from stlport to libc++. STL selection is done
with LOCAL_CXX_STL (valid values are default, none, libc++,
libc++_static, stlport, stlport_static, bionic).
The selection of the STL is as follows:
if LOCAL_CXX_STL == 'default'
ifdef LOCAL_SDK_VERSION
Use whatever STL the other NDK options have selected.
else
Use bionic's libstdc++ for target, GNU libstdc++ for host. This
is compatible with the existing build options.
endif
else
if LOCAL_CXX_STL == 'stlport'
Use stlport.
else if LOCAL_CXX_STL == 'libc++'
Use libc++.
else if LOCAL_CXX_STL == ''
Don't use any STL.
endif
endif
Bug: 15193147
Change-Id: If712ba0ae7908d8147a69e29da5c453a183d6540
We've been using -fPIC and -fPIE together in the global cflags all this
time. These options are incompatible. The only reason we haven't been
hit by this before is because of the forced -Bsymbolic in GCC. To fix
this, pass -fpic when compiling objects for shared libraries and -fpie
when compiling objects for executables. For static libraries, also use
-fpic. We have to do this because static libraries might be included in
either a shared library or an executable. Code compiled with -fpie
cannot be included in a shared library, but code compiled with -fpic
may be included in an executable.
We've also been using -fpic and -fPIC together. These are different
options, and only the latter will take effect.
http://stackoverflow.com/a/967010
The final thing this fixes is that we had -f(PIC|PIE) flags being passed
to link commands. These are compile time flags, and don't do anything at
link time.
Bug: 16823325
Change-Id: Ic76f47e63dc2c81b7e1a8058bae1b3dc8565d606
Use 4.9 mips64el toolchain for both 64- and 32-bit builds.
Tell ld when 32-bit links are required.
Override 4.9's changed defaults for mips floating point
register use, to get same assembler rules as 4.8 and earlier.
Also: drop unused soft-fp build targets, cleanout redundant
compiler options, and remove extraneous Android.mk file.
Change-Id: I86f1075266349edb2b08a7709b9f5472d8cfda32
This is causing issues when tools like asan try to wrap calls like
malloc. See the referenced bug for more details.
Bug: 15432753
Change-Id: I15e8eab5b773afd02dc14c78500cf8246a617718
Projects using stdatomic.h needs libatomic.a in case compiler can't
expand all __atomic* intrinsics. eg, __atomic_is_lock_free in
armeabi/mips.
Adding libatomic.a globally makes more sense than adding
"LOCAL_LDLIB += -latomic " in each project including <stdatomic.h>.
Projects don't need atomic operations won't get redundant DT_NEEDED
entry because libatomic.a is not a shared library.
Change-Id: I81dbf524544c848e667e18ab5eeabff75b5063ef
GCC know a few pre-defined paths (relative to its location) to
search for headers, libraries, program, etc. By default GCC prefixes
its own path(argv[0]) and calls realpath() which result in absolute
path with all symlink, . and .. removed.
It's usually good to have canonicalised paths, but absolute paths
in *.d file can cause unnecessary relinking when stale entries
in ccache cache hit
Add -no-canonical-prefixes (gcc>=4.6) and
-fno-canonical-system-headers (gcc>4.6) to disable realpath() on
prefixed paths
Change-Id: I58d739e61fb013015fb05a9c98b2132b307f915a
Use LOCAL_LDLIBS to link against prebuilt libraries (such as NDK
libraries).
Previously LOCAL_LDLIBS only applies to host modules and the behaviour
confuses users.
Change-Id: I515546d7b59ef54e8ef09050eb58ec63534c9291
When LOCAL_STRIP_MODULE := keep_symbols is set, then the normal strip rules
will be modified so that only the .debug_* sections are removed. The original
symbol table is left alone.
This allows the compilation of certain libraries so that libbacktrace library
can provide meaningful names to functions.
Bug: 12958251
Change-Id: I82bdc304a463012e29086325ccb51163464cb4a9
arm and arm64 have distinct headers, but mips and mip64, and x86 and x86_64
use headers that work for both widths. So where arm/arm64 need to handle the
second architecture case specially, all we need to do for the others is
hard-code the name. (x86_64.mk already hard-codes x86; we need to change
x86.mk for the case where we're building the 32-bit binaries for a mixed
system. mips64.mk doesn't exist yet, but when it does, it'll hard-code
just plain "mips" too.)
Change-Id: Ia6b9f77b4eb2c78729b454045875c409e0ea8197
This should never have been on the default include path.
The NDK statically links its own libthread_db, so I'm removing
bionic's unused copy from devices.
Bug: 11882807
Change-Id: I49a67fe0902cc4bc178360f6c993959774d74e3a
This is the first step to build 32-bit libraries in a 64-bit product.
It will work like this:
1) In the product's BoardConfig.mk, define:
TARGET_2ND_ARCH, TARGET_2ND_ARCH_VARIANT, TARGET_2ND_CPU_VARIANT.
The build system uses those variables to set up an additional compiler
environment for the second arch.
2) When parsing Android.mks, the build system sets up rules to build a
module for both the 1st arch and the 2nd arch, unless it's explicitly
asked to skip so.
Android.mk will be adapted if there is additional rule of generating
source files.
The build system will accept arch-specific LOCAL_ variables, such as
LOCAL_CFLAGS_arm, LOCAL_CFLAGS_armv7-a-neon, LOCAL_CFLAGS_cortex-a15,
LOCAL_CFLAGS_aarch64 etc. Modules use such variables to set up build for
various archs at the same time.
3) Install binary of the 2nd arch by adding "<module_name>:32" to
PRODUCT_PACKAGES. All 2nd-arch libraries linked in by "<module_name>:32"
will be installed automatically.
Bug: 11654773
Change-Id: I2df63cd5463a07bf5358bee2a109f8fb9590fe30
Conflicts:
core/combo/TARGET_linux-arm.mk
For global declaration of FDO profile generation and usage,
we need to link PRIVATE_TARGET_FDO_LIB (libgcov.a by default)
prior to linking shared libraries.
TARGET_FDO_LIB is set if feedback directed optimizations
are in use, so we do not need to worry about consistent size
increases from this change.
Change-Id: I543903f58893816f037c9466f31b19dfe822fdf4
Enable _FORTIFY_SOURCE=2 for x86 and MIPS.
Currently, this change is a no-op, as Android's libc doesn't
support _FORTIFY_SOURCE > 1, yet.
The ARM change was made in 316f720b91
Change-Id: Iafe90beadf9b6a41ea294b7107cf4f18141acf3a
Add -D_FORTIFY_SOURCE=1 to the default cflags
Update build rule for executable with PRIVATE_ALL_WHOLE_STATIC_LIBRARIES
Use single dash version of -print-whatever
compile everything with relro / bind_now
Enable NX protections
Some other cleanups to reduce differences between ARM and MIPS config files
Change-Id: I30b4de449e6353b581ef7f9437a3bb9be53d5bbf
Signed-off-by: Chris Dearman <chris@mips.com>
Error "cc1plus: error: unrecognized command line option
‘-mfloat-abi=softfp’" is much more confusing than
"...gcc: No such file or directory".
Also we don't build in Windows/Cygwin any more so we don't need the old
trick.
Change-Id: Ibbe3da67b412575e56bd6e61ef412ea5b2789fea
Otherwise the previously exported value will be sticky and the value
defined in the TARGET makefile is ignored.
Change-Id: I13b9cca2d288f7ab09104c57e7cad9f23de2548a
Default to 4.6, but can overwritten to something else in
prebuilts/gcc/$os/$arch/$arch-linux-android*-$ver
Change-Id: I16f99d642b8ff8e831d392261a0c536041107051
Use "LOCAL_SDK_VERSION := <number>" to build against the NDK when you
include $(BUILD_EXECUTABLE).
Bug: 7170098
Change-Id: I4cebeae3355e79a4d2f2f5549ef0613ced77e3f0
