tequilaOS/platform_build
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
platform_build/core/host_executable_internal.mk

61 lines
2 KiB
Makefile
Raw Normal View History

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-04-17 19:03:35 +02:00
###########################################################
## Standard rules for building an executable file.
##
## Additional inputs from base_rules.make:
## None.
###########################################################
ifeq ($(strip $(LOCAL_MODULE_CLASS)),)
LOCAL_MODULE_CLASS := EXECUTABLES
endif
ifeq ($(strip $(LOCAL_MODULE_SUFFIX)),)
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-08-14 21:59:50 +02:00
LOCAL_MODULE_SUFFIX := $($(my_prefix)EXECUTABLE_SUFFIX)
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-04-17 19:03:35 +02:00
endif
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-30 01:18:40 +01:00
ifdef host-executable-hook
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-04-17 19:03:35 +02:00
$(call host-executable-hook)
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-30 01:18:40 +01:00
endif
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-04-17 19:03:35 +02:00
skip_build_from_source :=
ifdef LOCAL_PREBUILT_MODULE_FILE
ifeq (,$(call if-build-from-source,$(LOCAL_MODULE),$(LOCAL_PATH)))
include $(BUILD_SYSTEM)/prebuilt_internal.mk
skip_build_from_source := true
endif
endif
ifndef skip_build_from_source
include $(BUILD_SYSTEM)/binary.mk
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-08-14 21:59:50 +02:00
my_host_libprofile_rt := $($(LOCAL_2ND_ARCH_VAR_PREFIX)$(my_prefix)LIBPROFILE_RT)
Use prebuilt libclang_rt.profile. Bug: 17574078 Change-Id: I4838cd5d125a0b2bf76aad2fdaef1ee3122687e8
2015-01-26 01:20:57 +01:00
$(LOCAL_BUILT_MODULE): PRIVATE_HOST_LIBPROFILE_RT := $(my_host_libprofile_rt)
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-03-02 22:54:51 +01:00
my_libdir := $(notdir $($(LOCAL_2ND_ARCH_VAR_PREFIX)$(my_prefix)OUT_SHARED_LIBRARIES))
ifeq ($(LOCAL_MODULE_CLASS),NATIVE_TESTS)
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 08:08:53 +02:00
$(LOCAL_BUILT_MODULE): PRIVATE_RPATHS := ../../$(my_libdir) ../../../$(my_libdir)
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-03-02 22:54:51 +01:00
else
$(LOCAL_BUILT_MODULE): PRIVATE_RPATHS := ../$(my_libdir) $(my_libdir)
endif
my_libdir :=
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-10 00:52:56 +01:00
my_crtbegin :=
my_crtend :=
my_libcrt_builtins :=
ifdef USE_HOST_MUSL
my_crtbegin := $(SOONG_$(LOCAL_2ND_ARCH_VAR_PREFIX)HOST_OBJECT_libc_musl_crtbegin_dynamic)
my_crtend := $(SOONG_$(LOCAL_2ND_ARCH_VAR_PREFIX)HOST_OBJECT_libc_musl_crtend)
my_libcrt_builtins := $($(LOCAL_2ND_ARCH_VAR_PREFIX)$(my_prefix)LIBCRT_BUILTINS)
$(LOCAL_BUILT_MODULE): PRIVATE_LDFLAGS += -Wl,--no-dynamic-linker
endif
$(LOCAL_BUILT_MODULE): PRIVATE_CRTBEGIN := $(my_crtbegin)
$(LOCAL_BUILT_MODULE): PRIVATE_CRTEND := $(my_crtend)
$(LOCAL_BUILT_MODULE): PRIVATE_LIBCRT_BUILTINS := $(my_libcrt_builtins)
$(LOCAL_BUILT_MODULE): $(my_crtbegin) $(my_crtend) $(my_libcrt_builtins)
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 07:59:53 +02:00
$(LOCAL_BUILT_MODULE): $(all_objects) $(all_libraries) $(CLANG_CXX)
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-04-17 19:03:35 +02:00
$(transform-host-o-to-executable)
endif # skip_build_from_source
Reference in a new issue Copy permalink