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
If LOCAL_CLANG is not set to false for a host module, clang will be used instead of gcc.
This also enables the integrated assembler by default for Darwin host builds.
bug 16172793
Change-Id: If7484c5dbcccce7d925bec97bff0a3e4c30e9434
Previously we only expanded product_MODULES with LOCAL_REQUIRED_MODULES,
but not modules introduced by LOCAL_SHARED_LIBRARIES; Later we did a further
shared libary expansion in vendor_module_check.mk.
It couldn't track C in the following case:
A : B, by LOCAL_SHARED_LIBRARIES; B : C, by LOCAL_REQUIRED_MODULES.
With this change, we transformed the LOCAL_SHARED_LIBRARIES dependencies
into LOCAL_REQUIRED_MODULES dependencies before doing the required
module expansion and the loophole is closed.
All module names are now expanded to product_MODULES now and it makes
vendor_module_check.mk simpler.
Change-Id: I8835a478d2ce0ce10601a8449f446f07b01c2b7f
Previously the RS cpp files are generated by the timestamp rule. Though
we have the generated RS cpp files depend on the timestamp file, we
don't have a build recipe. In such case gmake does some "optimization"
that it skip recompiling the generated cpp files, because it assumes the
generated cpp files are already up to date even if the rs files have
been updated.
Bug: 15313144
Change-Id: Ie69ecd2c788057d3619f9c7d2a125d44c4a534a1
This fixed issue that gnumake skip updating the cpp file that includes
the generated header file when the .proto file gets updated.
For example:
Say a.cc includes b.pb.h, since b.pb.h is just byproduct of the rule
that generates b.pb.cc, and though we have dependency "b.pb.h :
b.pb.cc", but we don't have build recipe for that rule.
Gmake stupidly thinks that b.pb.h must not be updated in that case so
it skips all targets that depends on b.pb.h!
With the dumy build recipe, gmake now doesn't skip the depedent targets.
Bug: 13009798
Change-Id: I39adc09b7656bdd023f578fb8933667944fd974c
This change basically ported our target multilib to the host side.
It supports 2 host build modes: x86 and x86_64 multilib build.
For now you need to set "BUILD_HOST_64bit=true" to switch to x86_64
multilib build. Later we'll default to x86_64 build and have a flag
to force 32-bit only build, which may be needed by SDK build.
In host module definition, like in target ones, you can use the
following
LOCAL variables to set up multilib configuration:
LOCAL_MULTILIB: can be "both", "first", "32" or "64".
It also supports the same set of arch or 32-vs-64 specific LOCAL
variables.
By default, it builds only for the first arch.
To keep path compatibility, in x86_64 build files are still output to
out/host/linux-x86; Both 32-bit and 64-bit executables are in
out/host/linux-86/bin;
In x86_64 build 32-bit shared libraries are installed to
out/host/linux-x86/lib32
and 64-bit shared libraries are installed to out/host/linux-x86/lib;
32-bit object files are output to out/host/linux-x86/obj32 and 64-bit
object files
are output to out/host/linux-x86/obj.
Bug: 13751317
Change-Id: I6044f83b7db369a33e05209e8c588eb6dc83409f
- Automatically export the include path of the generated .pb.h files
- Set up the dependency to make sure the .pb.h files get generated
before any dependent c/c++ files get compiled.
With this change, any module that links a proto library doesn't need
any extra setup.
Bug: 14563418
Change-Id: Iea7d19e9d8dce8e7d479c386b7a6151a95a0a0df
prebuilts/ndk/current/platforms/android-19/arch-x86_64/usr/lib
is renamed to usr/lib64 to be more consistent with rest of
lib paths in x86_64 toolchain, which is multilib
See https://android-review.googlesource.com/#/c/92441/
Change-Id: I4e59245505d0fa87ae3608e81e715ccfcecc5ec8
Change runtime library name to keep in sync with upstream.
Enable frame pointers in instrumented code for fast stack unwind.
Change-Id: I815912bb856c56c399639ea76ad4cb6b97961840
* commit '8295d6cd62ba73ea66e64204d2d0ea27b4b34889':
add support for LOCAL_MODULE_STEM_32 and LOCAL_MODULE_STEM_64
add support for LOCAL_MODULE_PATH_32 and LOCAL_MODULE_PATH_64
Some executables will need to be built for both 32-bit and 64-bit.
For tests, it will be convienient to keep the name of the executable
the same, but install them in a different location. Add
LOCAL_MODULE_PATH_32 and LOCAL_MODULE_PATH_64 to allow a module
to specify different paths for 32-bit and 64-bit executables.
Change-Id: I3be830e899c6d485fe55c25c66b20b3fe64c795e
Previously we have only one set of include/lib paths for
LOCAL_NDK_STL_VARIANT:=gnustl_static regardless of GCC
version, which is wrong because each GCC version
come with its own libstdc++.
Change-Id: I2a01c2120b6948aedce00e2f8d08dfc6932126dd
Previously the installed shared library dependency doesn't include
modules introduced by LOCAL_SHARED_LIBRARIES_<arch>.
This change fix the problem.
It also cleans up use of the shared library variable.
Bug: 13528787
Change-Id: Id8d807cc57f0ec4a71f18b64545d91191efad8fb
So a library can export the proto's include path that can be used with
both archs in multilib build.
Change-Id: Ia0f92f0b40e39dc3fa426c69c52139a0a8f04077
So a library can export the proto's include path that can be used with
both archs in multilib build.
Change-Id: Ia0f92f0b40e39dc3fa426c69c52139a0a8f04077
This makes sure copy_headers.mk only be included onces, no matter
it's for the 1st arch or the 2nd arch.
Change-Id: I80a558fbdb52861f176bd27a21c302069a5cc3ce
This fixed issue that gnumake skip updating the cpp file that includes
the generated header file when the .proto file gets updated.
For example:
Say a.cc includes b.pb.h, since b.pb.h is just byproduct of the rule
that generates b.pb.cc, and though we have dependency "b.pb.h :
b.pb.cc", but we don't have build recipe for that rule.
Gmake stupidly thinks that b.pb.h must not be updated in that case so
it skips all targets that depends on b.pb.h!
With the dumy build recipe, gmake now doesn't skip the depedent targets.
Bug: 13009798
Change-Id: I39adc09b7656bdd023f578fb8933667944fd974c
The LOCAL_*_$(TARGET_ARCH) variables don't make sense for host
modules, only append use them for target modules.
Also complete the list of LOCAL_*_arch and LOCAL_*_32/64 to be
consistent.
Change-Id: I00c83e5c4e08ed9a844f9f99a79ce4bcc3f0bf11
1. Following the setup of gcc in build/core/combo/,
we added the [HOST|TARGET]_<arch>.mk clang config files,
and load only the configs needed by the current product.
2. Added support for the 2nd arch.
Change-Id: I2a383418a9688a050b39492f8e489d40eeeb5f2d
Support the following new variables based on whether the current multilib
target is 32 bit or 64 bit:
LOCAL_CFLAGS_32
LOCAL_CFLAGS_64
LOCAL_LDFLAGS_32
LOCAL_LDFLAGS_64
LOCAL_ASFLAGS_32
LOCAL_ASFLAGS_64
LOCAL_C_INCLUDES_32
LOCAL_C_INCLUDES_64
Change-Id: Ia868d56dff114be301bf8297eec768675f186927
To ease the transition between toolchains, allow a target to specify
a list of cflags that the toolchain does not support. These will be
filtered out of the cflags provided by the module.
Add TARGET_GLOBAL_UNSUPPORTED_CFLAGS := -fstack-protector for the
aarch64 toolchain, it does not yet suport -fstack-protector.
Change-Id: I168d0c6f131326fad305ec86fad46e6a3e03295a
Allow modules to generate source into $OUT/gen, which will then
be copied into $OUT/obj and $OUT/obj_$(TARGET_2ND_ARCH) as
necessary. This allows a single build rule invocation that includes
generated source to build for the first and second architectures.
Modules will need to change calls to local-intermediates-dir into
local-generated-sources-dir.
Change-Id: I62504bad9454b3d9fde7b84ab9f0a487a2ecf0bf
Set arm_objects_mode and normal_objects_mode when building a
module for arm when it is the 2nd arch.
Change-Id: I5f7df519b6e1dde6cbf92d106681f07a58e1f1f2
With those variables, you can set up different values for TARGET_ARCH
and TARGET_2ND_ARCH.
Also fixed a couple of variables.
Bug: 11654773
Change-Id: I4c7684a562cd5877d18f67d4f848b8df07d0103b
Conflicts:
core/base_rules.mk
The rules for the 2nd arch are set up in the second inclusion
of static_library_internal.mk.
libfoo of the 2nd arch will be built into
$(PRODUCT_OUT)/obj_$(TARGET_2ND_ARCH)/libfoo_intermediates/libfoo.a.
Bug: 11654773
Change-Id: I1d92733968fc442e9225b4df5bd1b551a81d89f7
The new option WITH_STATIC_ANALYZER=1 instructs build system to
run static analyzer via "clang --analyze" on a successful build.
If analyzer finds any issue, instruction to open report is displayed.
See http://clang-analyzer.llvm.org/scan-build.html for details.
WITH_STATIC_ANALYZER trumps WITH_SYNTAX_CHECK if both exist.
Project use lots of GCC extensions (eg. nested function) not supported
by clang may opt out by adding LOCAL_NO_STATIC_ANALYZER:=true
Change-Id: I9970560560bd52ce5f0fd7129c3488629627c735
The new option WITH_SYNTAX_CHECK=1 instructs build system to invoke
"clang -fsyntax-only" to utilize clang's better diagnostics before calling
LOCAL_CC/LOCAL_CXX for code generation. The compilation time is slightly
longer, and the generated object file should be the same as w/o WITH_SYNTAX_CHECK
Project use lots of GCC extensions (eg. nested function) not supported
by clang may opt out by adding LOCAL_NO_SYNTAX_CHECK:=true
Change-Id: I5689586788ef049bd967364f71f31f1e359bd121
The issues:
- The size increase from utilizing FDO is quite large while
utilizing runtime profiles in build.
- By default, FDO is utilized globally if the target arch variant
profiles exist.
- Not all modules can show statistical significance in
performance comparison, yet still suffer the size increase.
The solution:
- Only enable FDO locally with LOCAL_FDO_SUPPORT
for modules which may benefit enough to justify the size
tradeoff.
Solution notes:
- I've noted statistical significance in libwebcore and libskia
thus far from utilizing FDO.
- Analysis included sunspider, drawcanvas benchmarks, as
well as gooda analysis on both arm and x86
- To support runtime profile generation in modules which have
LOCAL_FDO_SUPPORT specified,
BUILD_FDO_INSTRUMENTATION is still used. Otherwise,
if the target arch variant profiles exist, FDO is utilized for
specified modules.
Change-Id: I7e95266943ff47c7d82b02e6200fd09911d0bb57
Rule-generated .o files (in gen_o_objects) were being given a dependency
on everything in LOCAL_GENERATED_SOURCES (except for other .o files);
unfortunately this can still create cycles in cases where there are
explicit dependencies between entries in LOCAL_GENERATED_SOURCES.
Instead, make handling of generated .o files consistent with other
generated files (which don't automatically get any dependencies on other
generated files) by excluding them from the target side of the rule.
Change-Id: I3fb5652dc3d85012c179a03b81887d16a85ab3bf
Now you can have a board config variable BOARD_HAL_STATIC_LIBRARIES,
which is a list of board-specific HAL static library names with pattern
"lib<library_name>.<board_specific_suffix>". LOCAL_HAL_STATIC_LIBRARIES
is a list of "lib<library_name>" and any matched
BOARD_HAL_STATIC_LIBRARIES will be added to the LOCAL_STATIC_LIBRARIES;
if no match is found, lib<library_name>.default will be used.
Bug: 10262105
Change-Id: Ic89d8d417d1dd65a227e4187a157fd3b77c4af34
Summary:
If built with BUILD_FDO_INSTRUMENT alone, host modules will fail at runtime (during build)
due to failing to create /data in most standard unix user permission cases. If the user does
have full permission to /, /data/profile/ will be created and profiles will be generated there.
Any file generation in the Android Build System should be kept to $OUT.
This commit fixes this bug.
Test Plan:
Build with BUILD_FDO_INSTRUMENT without additional configuration, and host modules will no longer generate profiles
at their runtime.
Since commit 6c86a1 we have split LOCAL_SHARED_LIBRARIES out of
LOCAL_REQUIRED_MODULES and the vendor check does no longer cover the
installed modules introduced by LOCAL_SHARED_LIBRARIES.
This change brings back the coverage.
Change-Id: Ie78692e48f173a3350792eb2fee8127ff9433caa
webviewchromium has some build rules which use a custom tool to create
.o files from other input (i.e. they are not prebuilt and so can't be
included in LOCAL_PREBUILT_OBJ_FILES). Support adding .o files to
LOCAL_GENERATED_SOURCES and doing the right thing with them (including
them in the static/dynamic library or executable being built).
Bug: 7714333
Change-Id: I3b1d29eeff30aebeafe33398f9bef2eb6972d997
Before this, if there are duplicate module names in both the host and
target spaces, LOCAL_SHARED_LIBRARIES results in mixed dependencies.
Bug: 7026946
Change-Id: I5407e3d078a8903c94978cc6d3e256851c52340f
Use "LOCAL_SDK_VERSION := <number>" to build against the NDK when you
include $(BUILD_EXECUTABLE).
Bug: 7170098
Change-Id: I4cebeae3355e79a4d2f2f5549ef0613ced77e3f0
Use "LOCAL_SDK_VERSION := <number>" to build against the NDK when you
include $(BUILD_EXECUTABLE).
Bug: 7170098
Change-Id: I4cebeae3355e79a4d2f2f5549ef0613ced77e3f0
To pass compiler flags
LOCAL_CFLAGS: to both C and C++ files;
LOCAL_CONLYFLAGS: to only C files but not C++ files;
LOCAL_CPPFLAGS: to only C++ file.
LOCAL_CPPFLAGS and LOCAL_CONLYFLAGS can override flags in LOCAL_CFLAGS.
Bug: 6967573
Change-Id: I88d9de0980e451b94bc7ae8c741ea2030eada3e1
We are now unifying the NDK versions of unbundled native code to always
use the latest NDK.
We don't need the variable LOCAL_NDK_VERSION now.
To build native code with NDK, you need set just LOCAL_SDK_VERSION.
Bug: 6932421
Change-Id: I86f05a264249cda6bae97b4b1616f03700cd9dfa
We are now unifying the NDK versions of unbundled native code to always
use the latest NDK.
We don't need the variable LOCAL_NDK_VERSION now.
To build native code with NDK, you need set just LOCAL_SDK_VERSION.
Bug: 6932421
Change-Id: I86f05a264249cda6bae97b4b1616f03700cd9dfa
Bug: 6383397
Note that LOCAL_MODULE_MAKEFILE is calculated in the macro my-dir,
which must be called at the beginning of your Android.mk to calculate
LOCAL_PATH.
Change-Id: I7aa079e37253fbda25ffb85c2e5bbf0663340e27
Adds arm_neon.h to the include path when building with Clang.
Filters out 3 additional compiler flags when building with Clang.
Filters out unsupported flags from TARGET_(arm|thumb)_CFLAGS, as well.
Change-Id: I5e23a95356e0b10c31c9aa3cb4905f6a674709e4
Generate C++ code for all .proto files before attempting
to compile them. This takes care of the case where generated
.pb.cc files include other header / c++ files due to proto
imports in the original .proto files.
Change-Id: I26513842618fd31f0b33a3f10df2a5e556094515
base_intermediates is not used anywhere in the main build system,
and should not be part of LOCAL_C_INCLUDES. It is used by
external/webkit/Android.mk as a local variable, which causes
the libwebcore_intermediates directory to be added to the include
path for every module.
Change-Id: Iddeee880add4b6f694a15d1900c588e1c547b9df
The notice_files target generates $(TARGET_OUT_INTERMEDIATES)/NOTICE.txt and
$(TARGET_OUT_INTERMEDIATES)/NOTICE.html. The former is not needed and the
latter is an explicit dependency of $(TARGET_OUT_INTERMEDIATES)/NOTICE.html.gz.
We can therefore remove the target and the logic to generate NOTICE.txt.
Change-Id: I6179c049bebe590c7298e8be0a30e30265423468
Bug: 5573756
With this change, we can set LOCAL_EXPORT_C_INCLUDE_DIRS in the module
definition to export include dir paths.
Paths in LOCAL_EXPORT_C_INCLUDE_DIRS should be relative to the top dir
of the source tree.
If a library (shared or static) exports some include paths, any module
using it will import the include paths and add them to the compiler
command line.
Change-Id: I49aabc589d2cf214044d13ccd5532ef68209adf0
Bug: 5200343
Before this change the build system assumes that shared libraries will
be installed to $(TARGET_SHARED_LIBRARIES). That's not true if the
module uses custom LOCAL_MODULE_PATH.
With this change we defer the evaluation of the dependency to after all
Android.mks are loaded and all modules have their installed path
determined.
Change-Id: Ib6628ed44154a90e8668d31691fbbac67125be6c
Set LOCAL_GROUP_STATIC_LIBRARIES := true to group the static libraries,
in case we need gcc flags "-Wl,--start-group" and "-Wl,--end-group" to
fix circular references.
Change-Id: I03c4901670112fcdd2bb0fe660b6924e5776fcf8
LOCAL_NDK_STL_VARIANT can be set to system, stlport_static, stlport_shared
or gnustl_static. It defaults to system.
Change-Id: I2840d30ff732a00bc0ea70eab8a8179aea0abbdf
For some reason, all_objects was not listing objects generated from
objective-C sources. We need these for the emulator (which builds its
own version of SDL which uses Quartz on OS X).
+ Fix a typo in transform-host-m-to-o definition.
This also explains why https://review.source.android.com/#change,21074
had to be reverted, since it gets rid of the prebuilt SDL libraries when
building the emulator.
Change-Id: I173811cf11cdb5b045073aade59364236145bc77
Added LOCAL_NO_CRT to enable building executables that do not link
to the C runtime library.
Removed support for LOCAL_MODULE_SUBDIR since it was broken
and unused. (Was going to use it but ended up using LOCAL_MODULE_PATH
instead.)
Change-Id: I3b6f5ab7e5ae6aaa7119899adccece2b4ab1cbb3
