Improves performance for LOCAL_WHOLE_STATIC_LIBS by copying the first .a
to the new .a rather than extracting and recreating
Change-Id: Iecdb5e4bb2ce987bb41a70c3393d18a6d72ae689
This fixes mips unbundled build since we switched to mips64el toolchain
for both mips and mips64.
TODO: multilib build support.
Change-Id: I7add92d2cecfc3ab739785ceef6700240a25093a
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
Dx is now capable of generating multiple dex file in one run.
This capability is not compatible with --output=*.dex so this CL
changes the --output argument to be a directory. This CL also
includes the packaging of the multiple dex files when dx generates
more than one dex file.
(cherry picked from commit 8ffe9c3e79)
Conflicts:
core/java.mk
Change-Id: I1ddc91b416de5929d4d4b41824c6012b32f94deb
Use "LOCAL_MULTILIB := both" to install jni libraries of both archs in
multilib build.
The build system will package jni of both archs to the apk, or install
them to the right location on the system image and create symlinks,
extract .so files from prebuilt apk, etc if appropriate.
Bug: 15849902
Change-Id: I7e147b5a47db476584c38250de7b36c75ea40d81
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
_extract-and-include-single-(host|target)-whole-static-lib was written such that
only the first file of a given name would be extracted and included into the new
library. This patch iterates over each identically named archive member,
extracts them individually, and adds them to the new archive.
Bug: 15110069
Change-Id: Ia08c7be6f40bfc8403908a8808898ada479099b1
Previously the odex file is byproduct generated by the package.apk rule.
Though we have the odex file depend on the package.apk it doesn't have
its own build recipe. In case package.apk isn't updated but we still
need to update the odex file (such as changed LOCAL_MULTILIB), the odex
file will never be rebuilt.
This change split out the rules to build the odex file and make sure the
build recipe get executed if the odex file needs rebuild.
Change-Id: I60c2f32b536b3d59045301ee863aae1451734aad
We already support pure 32-bit and 64-bit-by-default multilib build.
With HOST_PREFER_32_BIT we can build 32-bit-by-default multilib build.
This will be lest disruptive during the period we transition to
64-bit-by-default.
Bug: 13751317
Change-Id: I0d56ce4abbe4afeaacfd70d709f6a349791c0722
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
"GYP" class targets are used by external/chromium_org for gyp's "none"
type. The processing in these targets needs a separate intermediate
directory for the primary/secondary architecture, so add it to the list
in intermediates-dir-for along with libraries/executables.
Change-Id: Id05899c83b45ed0647dfbfa6b0b2e7f61b04348b
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
Depending on the file extension of the generated C++ file,
bison will generate a #include of a .h or .hpp. So both files
must be kept in the generated directory.
Change-Id: Id0aac7f407bdc69c7f5012c0d021761b0fceb427
For host executables and shared libraries, the global LDFLAGS were being
inserted into the linker command line after the module-specific ones,
making it impossible to override the default settings. Change the order
to match target linker invocations.
Change-Id: Icd5f6f83df9f27a5be97ddb197ee245c1ab8c2be
