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
So we can have the same set of module names in different host arch
/ toolchain version combinations.
Change-Id: Iec66584bf3de92aedd71a59f9dbe74b6ed025b2e
When copying files from file systems that support high resolution
mtime, we should not truncating the nsec part. Instead we should
increase the dst mtime by one sec to prevent dst mtime to become less
than src mtime.
Change-Id: I2b4200c72c4e6ee8aae875b5e64701324799afc7
When copying files from file systems that support high resolution
mtime, we should not truncating the nsec part. Instead we should
increase the dst mtime by one sec to prevent dst mtime to become less
than src mtime.
Change-Id: I5cab1edd4b9783ec0e3ceb04ed833d8bbba00b19
Depending on libutils causes a build layering violation,
requiring frameworks/base/... for libhost...
Signed-off-by: Brian Swetland <swetland@google.com>
