Now that copy-file-to-target doesn't use acp, nothing in the acp build
path uses acp, so we don't need to special case it to prevent loops.
Change-Id: I12810c1b064d0c03135a80077a76bc4c9cc18b24
This was never defined anywhere and only Windows doesn't have
a valid st_ino field on struct stat.
bug: 26355387
Change-Id: I40b8779606057281e2e6a2723ef93cd2f2d99a68
direct.h declares _mkdir() on Windows.
Prevent future compiler warnings with -Wall and -Werror.
Bug: 26355209
Test: `mmma -j30 build/libs/host` for aosp_arm64-eng is successful.
Change-Id: I6d6e4edca98bef57d62829e9d1ef4e2a96cdad3d
Instead of wrapping a host module definition in 'ifeq($(HOST_OS),...)'
in the Android.mk files, define which hosts are supported using
LOCAL_MODULE_HOST_OS.
A blank LOCAL_MODULE_HOST_OS means that linux and darwin are supported.
A non-empty LOCAL_MODULE_HOST_OS lists the supported HOST_OSs.
Change-Id: I1e342d1908cfa00aef2c39c145b4f5f81c373bc6
So that we can support building both linux and windows binaries at the
same time on a linux host. This replaces the ifeq($(HOST_OS),...) checks
in Android.mk files.
Bug: 23566667
Change-Id: I693e11984e36d55bb6f09fa0d49bc485463e16fb
We still support HOST_OS=windows for the SDK host tools cross-builds, but
that's only when USE_MINGW is set when running under linux.
Change-Id: I37da87dc9fbbd69ba10ce4d7f2668ab3f6482d92
Since acp is needed to build the ASAN libs, we can't use ASAN to
instrument it. Since libhost is included statically in acp, we can't
instrument that either.
Change-Id: Idb389df945380b6ef447fc3d3ead8be27ec09011
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>
