Commit graph

10 commits

Author SHA1 Message Date
Colin Cross
af7ac3986e Add basic musl support to make
There are still devices that set BUILD_BROKEN_USES_BUILD_HOST_* and
build host modules in Make.  Add basic support for building against
libc_musl in Make when USE_HOST_MUSL is set.

Bug: 258535366
Test: build a host tool defined in Android.mk file in internal branch
Change-Id: I9150be749bbeaac2ac5a33b2cf915004aa3033df
2022-11-09 16:40:25 -08:00
Dan Willemsen
c5b7c4fbef Add dependencies on the toolchain (clang, etc)
Historically, we've relied on the path to the clang compiler changing in
order to trigger rebuilds instead of direct dependencies on the compiler
itself. That's somewhat more reliable, since the actual $(CLANG) file is
often a script that doesn't actually change during every update.

In Soong, we've added the dependency anyway, so do it here as well. This
makes it easier for my RBE experiments to identify when we intend to use
clang and to send the entire compiler.

Test: treehugger
Test: build a system image with RBE, find that every command that needed
the compiler gets it.
Change-Id: I3838b5d77884394a8c0f7a1ba133142102602084
2019-06-12 21:34:52 +00:00
yangbill
59c616a263 Build System: Fix rpath error if native executable under testcase folder.
error while loading shared libraries: libc++.so:
cannot open shared object file: No such file or directory

BUG: N/A
Test: make -j16 liblatinime_host_unittests
      out/host/linux-x86/testcases/liblatinime_host_unittests/x86_64/liblatinime_host_unittests

Change-Id: I97738f728c29ab904fc979ff9b08a8d5bd1328cd
2018-05-07 06:29:12 +00:00
Dan Willemsen
893bebc44b Clean up some kati warnings
Kati has a `--warn` option that adds some extra Kati-specific warnings
-- like using undefined make functions, undefined user functions, likely
bad variable lookups, etc. Some of these are bugs, others are fine doing
nothing. This fixes up all of them in the core build system.

It also complains about $(eval) usage in a recipe not being recommended.
Those aren't handled as part of this change.

Bug: 72661763
Test: build-aosp_arm.ninja is identical before and after
Change-Id: I8e00af142a7745236d3ad4efc9e91ec3ce71a511
2018-01-29 16:23:37 -08:00
Dan Willemsen
7fe992c0cc Add NATIVE_TESTS class, move host native tests
Host native tests have been getting installed into
out/host/linux-x86/bin/..., but this pollutes the bin directory with a
lot of poorly named tests. Also, to support 32-bit and 64-bit tests, we
need to have different names with different suffixes. This causes
problems when tests expect to be named something specific (like gtest).
It's also convenient to store test data next to the test itself.

So with this change, native tests will be installed in
out/host/linux-x86/nativetest[64]/$(LOCAL_MODULE)/$(LOCAL_MODULE_STEM)
just like target tests get installed into /data/nativetest[64].

Implement this using a new NATIVE_TESTS class, which is like
EXECUTABLES, but sets up the install path differently, and configures
the rpath to load shared libraries with the proper relative path.
LOCAL_MODULE_RELATIVE_PATH can be used to control the directory name, it
will default to $(LOCAL_MODULE). This way multiple related tests can be
grouped together.

Target native tests also use NATIVE_TESTS now, but nothing should change
other than LOCAL_MODULE_RELATIVE_PATH can be used.

Change-Id: I535e42b1a6b21c5b8d6a580aa2f944d2be35e27d
2016-05-24 12:43:16 -07:00
Dan Willemsen
f1c09d7fbd Merge "Add HOST_CROSS_OS" 2015-09-09 18:13:21 +00:00
Dan Willemsen
057aaea54a Add HOST_CROSS_OS
Instead of using recursive make to change the HOST_OS when building the
windows SDK under linux, add the concept of cross-building to another
host os.

Bug: 23566667
Change-Id: I6dc525b601b6251d458d197c30bf4660d7485502
2015-09-09 18:12:29 +00:00
Dan Willemsen
ed635cfc0d Fix LOCAL_MODULE_HOST_OS
Make sure LOCAL_IS_HOST_MODULE is set before including
module_arch_supported.mk

Bug: 23566667
Change-Id: I28ef10f093407eb3a6a83574ecc3f098eb775241
2015-09-04 15:41:38 -07:00
Dan Albert
343ed674e3 Use prebuilt libclang_rt.profile.
Bug: 17574078
Change-Id: I4838cd5d125a0b2bf76aad2fdaef1ee3122687e8
2015-04-01 19:03:22 -07:00
Ying Wang
6feb6d5607 Support host multilib build
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
2014-05-14 16:55:04 -07:00