GitLab

So that we can disable only one in multilib modules.

Bug: 27442756
Change-Id: I4ca379fac997f9165c47cb93d34bf1f483f5a241

The relocation packer is part of prebuilts/misc, and pulling that
repository into the manifest requires pulling in a lot of other things
not needed by the simpler builds (like the clang toolchain manifest).

Bug: http://b/17441393
Change-Id: If4a94804fc1a3f81215b840247f8e332d0b510c1

When BREAKPAD_GENERATE_SYMBOLS is set to true, package the breakpad
symbols into the target files zip thats generated with `make dist`.

Bug: 24165970
Change-Id: I11c0d9a9d9e159475bfdb7bc338f9e9ac60aeada

When BREAKPAD_GENERATE_SYMBOLS is set to true, generate breakpad
symbols for binaries.

Bug: 23900817
Change-Id: I7b992d819350f4f80df5868d16f13016502dfca0

Bug: http://b/20665974
Change-Id: Ibc13b5d6bd05dfbc7ff8475068fe7363f58e7e67
(cherry picked from commit e24b6f77)

Bug: http://b/20665974
Change-Id: Ibc13b5d6bd05dfbc7ff8475068fe7363f58e7e67

  We need PT_LOAD segments to match for the gdb sake.
  If we pack module after stripping symbolic version
  PT_LOAD differ from actual ones; this confuses gdb.

Bug: http://b/20687795
Change-Id: If7b1ffcda918d0cc47051a30ca1202007ed62403
(cherry picked from commit 258b29cf)

  We need PT_LOAD segments to match for the gdb sake.
  If we pack module after stripping symbolic version
  PT_LOAD differ from actual ones; this confuses gdb.

Bug: http://b/20687795
Change-Id: If7b1ffcda918d0cc47051a30ca1202007ed62403

  Add replocation-packer step for dynmic executables.

  Enable it by default for arm and arm64 platforms.

Bug: http://b/18051137
Change-Id: I0c88fd31595bcea62a087f219acb9ecf9c80f2e5

This reverts commit e7a1b8a0.

Change-Id: I1a2185e1c68d364941e3b3e525a8c4a7a42e0cc1

Bug: http://b/18051137
Change-Id: I277277d5f5eb450ef9b4a23cfec16d75d977eb89

Change-Id: Ibb7da2997a0bb5b9f435213c9d3206bc4aad18db

Strip prebuilt shared library but not try adding gnu debuglink.
It would fail if you try run the adding gnu debuglink command if a
prebuilt is already stripped.

Bug: 17177288
Change-Id: If5811865715c2437e45fbd329983ef1212ef0109
(cherry picked from commit bfb52a2e)

In commit e9dd9f2b we moved "include $(BUILD_SYSTEM)/android_manifest.mk"
forward before the variable intermediates.COMMON gets defined. That's a
mistake.
This change replaced the tentative variables
package_expected_intermediates_COMMON and guessed_intermediates with
their proper counterparts defined in base_rules.mk.
If their values differ in the two file, that's an error and we should
fix.

Bug: 18168693
Change-Id: I2bf17b0476b4a7f97810fbb0bde7630eb8878b53

Strip prebuilt shared library but not try adding gnu debuglink.
It would fail if you try run the adding gnu debuglink command if a
prebuilt is already stripped.

Bug: 17177288
Change-Id: If5811865715c2437e45fbd329983ef1212ef0109

When LOCAL_STRIP_MODULE is keep_symbols, you can still use
STRIP_EVERYTHING_BUILD_VARIANTS in product configuration to strip
everything for some build variants, such as user build to save image
space.

Bug: 16897368
Change-Id: I2a1b7204e5c976387ddea8846c82e11a7b478d8d

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

Some executables will need to be built for both 32-bit and 64-bit.
For linker/linker64, debuggerd/debuggerd64, and a few more, they
will be installed in the same path (/system/bin), but with different
filenames.  Allow the module to specify LOCAL_MODULE_STEM_32 and
LOCAL_MODULE_STEM_64 to name the two versions.

Change-Id: I573e8678c7332245a064f31246be0a05f0a9e25f

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

LOCAL_STRIP_MODULE will be reused in multilib build.

Change-Id: I3512efb360c7eaafad02859723ab4368778effed

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 shared_library_internal.mk.
Intermediate fils of libfoo of the 2nd arch will be built into
$(PRODUCT_OUT)/obj_$(TARGET_2ND_ARCH)/SHARED_LIBRARIES/libfoo_intermediates/
and the built libfoo.so will be in
$(PRODUCT_OUT)/obj_$(TARGET_2ND_ARCH)/lib.

Bug: 11654773
Change-Id: I58bbe5a05a65f63bce6279131552f3792000716e

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

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

The rules for the 2nd arch are set up in the second inclusion
of shared_library_internal.mk.
Intermediate fils of libfoo of the 2nd arch will be built into
$(PRODUCT_OUT)/obj_$(TARGET_2ND_ARCH)/SHARED_LIBRARIES/libfoo_intermediates/
and the built libfoo.so will be in
$(PRODUCT_OUT)/obj_$(TARGET_2ND_ARCH)/lib.

Bug: 11654773
Change-Id: I58bbe5a05a65f63bce6279131552f3792000716e

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

Also this fixes the LOCAL_UNSTRIPPED_PATH if the module is installed to
the vendor dir via LOCAL_PROPRIETARY_MODULE.

Bug: 11289169
Change-Id: Ib07e5761411210963076487fe0e148c259e1e082

Also this fixes the LOCAL_UNSTRIPPED_PATH if the module is installed to
the vendor dir via LOCAL_PROPRIETARY_MODULE.

Bug: 11289169
Change-Id: Ib07e5761411210963076487fe0e148c259e1e082

With this change, you can install a shared library with module name foo
as bar.so to the system.img with:
LOCAL_INSTALLED_MODULE_STEM := bar.so
Note that we in general still disallow a static/shared library to
specify LOCAL_MODULE_STEM or LOCAL_BUILT_MODULE_STEM, because the build
system uses LOCAL_MODULE to compute build time dependencies, such as
export_includes, the -l linker flag etc.
Also, if you use LOCAL_INSTALLED_MODULE_STEM to change the installed
file name and if any other module links against this library, you may
run into runtime error: the library name baked in to the binary is not
the same as file name in the system image.

Change-Id: I55b571c8139c3bda07a4a0e50cea0f20d8d6c168

With this change, you can install a shared library with module name foo
as bar.so to the system.img with:
LOCAL_INSTALLED_MODULE_STEM := bar.so
Note that we in general still disallow a static/shared library to
specify LOCAL_MODULE_STEM or LOCAL_BUILT_MODULE_STEM, because the build
system uses LOCAL_MODULE to compute build time dependencies, such as
export_includes, the -l linker flag etc.
Also, if you use LOCAL_INSTALLED_MODULE_STEM to change the installed
file name and if any other module links against this library, you may
run into runtime error: the library name baked in to the binary is not
the same as file name in the system image.

Change-Id: I55b571c8139c3bda07a4a0e50cea0f20d8d6c168

Instead of incorrectly including global variable PRIVATE_CLEAN_FILES

Change-Id: I9b5e12448dad5001de051a566d8a94a89b20ecac

Orig-Change-Id: I61137f5bb123dc5f610af9928ed3debdf85ba74d
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>

Change-Id: I1628b54fc747154d48f213c634b081e43eb41696

This patch removes support for prelinking from the build system.  By now, the
prelinker has outlived its usefulness for several reasons.  Firstly, the
speedup that it afforded in the early days of Android is now nullified by the
speed of hardware, as well as by the presence of Zygote.  Secondly, the space
savings that come with prelinking (measued at 17MB on a recent honeycomb
stingray build) are no longer important either.  Thirdly, prelinking reduces
the effectiveness of Address-Space-Layout Randomization.  Finally, since it is
not part of the gcc suite, the prelinker needs to be maintained separately.

The patch deletes apriori, soslim, lsd, isprelinked, and iself from the source
tree.  It also removes the prelink map.

LOCAL_PRELINK_MODULE becomes a no-op.  Individual Android.mk will get cleaned
separately.  Support for prelinking will have to be removed from the recovery
code and from the dynamic loader as well.

Change-Id: I5839c9c25f7772d5183eedfe20ab924f2a7cd411

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: Ifed4ffe17003d90370c711ea6606e2b75e841dee

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

Cherry-pick from master.

Change-Id: I0a56e3e91efd53ad2671136b6fe00ee675f56230

Bug: 2953067

Change-Id: I12a0bdb1f3df4fa98bea70f60e0ce26bf863c924

Change-Id: I61137f5bb123dc5f610af9928ed3debdf85ba74d
Signed-off-by: Bruce Beare <brucex.j.beare@intel.com>