Make build system respect ALLOW_MISSING_DEPENDENCIES, when building
architecture B products, and ignore targets with dependencies that
are not available for architecture B.
Bug: 142701187
Test: # Add a dummy Android.bp with a module only for arm64
$ m -j TARGET_PRODUCT=aosp_x86 TARGET_BUILD_VARIANT=userdebug
Change-Id: I64de33674732df8c286671c806a07bcd19862b80
When an APEX is built with uses_sdks, any depedndency from the APEX to
the outside of the APEX should be from the SDKs that the APEX is built
against.
Bug: 138182343
Test: m
Change-Id: I1c2ffe8d28ccf648d928ea59652c2d0070bf10eb
The arch variants are hardcoded in every module type. Refactor
them out into a Target.Variations() method in preparation for
splitting the arch mutator into two, which will require using
different variations.
Test: m checkbuild
Change-Id: I28ef7cd5168095ac888fe77f04e27f9ad81978c0
apex_available property can be appended differently per the linkage
type. This will be used to restrict certain libs (e.g.
libc_malloc_debug) to an APEX while allowing them to be statically
linkable from platform for testing purpose.
Test: m (apex_test amended)
Change-Id: I6dec23129c5ac93a3ef06fea28f26f240c0ba410
Older VNDK libraries are provided as vndk_prebuilt_shared modules. Those
are added to corresponding VNDK APEX as dependencies.
With VNDK APEX installed, VNDK libs are unnecessary. By the way, since
there can be vendor modules which depend on VNDK libs, Make targets are
still emitted with UNINSTALLABLE=true.
Android.mk has additional modules for vndk libraries which are named
with apex name as suffices. For example, if libfoo is a vndk library,
then libfoo.vendor is its vendor variant and it would be in
/system/lib/vndk. But with vndk apex, it has additional
libfoo.com.android.vndk.current variant.
Bug: 141451661
Bug: 139772411
Test: m (soong tests)
Test: boot with aosp_arm64 system image on Q vendor device
Change-Id: I269c28a4d4c4e2f1518bd51df558438fe5316774
This change reverts following three changes to remove the no_apex
property. no_apex: true is equivalent to apex_available:
["//apex_available:platform"].
Revert "fix: "no_apex" can be put in defaults"
This reverts commit cc372c5b1d.
Revert "Add no_apex check for static library"
This reverts commit 2db7f46d0c.
Revert "Add no_apex property"
This reverts commit 4f7dd9b4db.
Bug: 139870423
Bug: 128708192
Test: m
Change-Id: Ia4b094e371e9f8adff94ae6dc3ebb8e081381d4e
The static properties don't make sense for cc_library_shared
modules, and the shared properties don't make sense for
cc_library_static modules. Move them into separate property
structs so they can be added conditionally.
Test: m nothing
Test: DefaultsTest
Change-Id: I0b0cedf9eba07deb721fae138ffa7bedcfbfe71e
This change introduces a new module type named 'sdk'. It is a logical
group of prebuilt modules that together provide a context (e.g. APIs)
in which Mainline modules (such as APEXes) are built.
A prebuilt module (e.g. java_import) can join an sdk by adding it to the
sdk module as shown below:
sdk {
name: "mysdk#20",
java_libs: ["myjavalib_mysdk_20"],
}
java_import {
name: "myjavalib_mysdk_20",
srcs: ["myjavalib-v20.jar"],
sdk_member_name: "myjavalib",
}
sdk {
name: "mysdk#21",
java_libs: ["myjavalib_mysdk_21"],
}
java_import {
name: "myjavalib_mysdk_21",
srcs: ["myjavalib-v21.jar"],
sdk_member_name: "myjavalib",
}
java_library {
name: "myjavalib",
srcs: ["**/*/*.java"],
}
An APEX can specify the SDK(s) that it wants to build with via the new
'uses_sdks' property.
apex {
name: "myapex",
java_libs: ["libX", "libY"],
uses_sdks: ["mysdk#20"],
}
With this, libX, libY, and their transitive dependencies are all built
with the version 20 of myjavalib (the first java_import module) instead
of the other one (which is for version 21) and java_library having the
same name (which is for ToT).
Bug: 138182343
Test: m (sdk_test.go added)
Change-Id: I7e14c524a7d6a0d9f575fb20822080f39818c01e
Adds the corpus and dictionary properties to the cc_fuzz target.
Propagates these entries to the makefile backend via LOCAL_FUZZ_DATA, in
a similar manner to LOCAL_TEST_DATA.
Bug: 141026328
Test: m example_fuzzer, fuzz target should have adjacent corpus/dict
files.
Change-Id: If5add5a597cc479f4e084bdafbd0fc175cfd6321
Vendor variant is now divided into several vendor.{version} variants,
depending on their intended usages:
vendor.{BOARD_VNDK_VERSION}: vendor and vendor_available modules
vendor.{PLATFORM_VNDK_VERSION}: VNDK modules in the source tree
vendor.{snapshot_ver}: VNDK snapshot modules
This also affects exported module names from Soong to Make. But to
maintain backward compatibility, ".{BOARD_VNDK_VERSION}" suffix will not
be emitted for modules having version BOARD_VNDK_VERSION, so that vendor
modules still can be referred as-is.
Bug: 65377115
Bug: 68123344
Test: clean build and boot blueline
Change-Id: Ib9016a0f1fe06b97e9423fd95142653a89a343fa
Bug: http://b/137883967
With coverage enabled, native-bridge modules throw a SEGV_ACCERR.
Test: Successfully run the app linked in the bug on a coverage build.
Change-Id: I9f3622b7b6d3189337c445a26d6bf81c96820c2e
Ensure that it ends up in the bionic/ subdir in the Runtime APEX and is
symlinked from /system/lib(64). That makes it available in the default
(platform) linker namespace and no longer requires it to be accessible
through the runtime namespace. All this makes it consistent with how the
other Bionic libs are handled, and avoids the need for various special
cases in ld.config.txt files (to be cleaned up later).
With this there might no longer be a need for a linker namespace for the
Runtime APEX, and we could consider removing the kludge with the
/apex/com.android.runtime/${LIB}/bionic subdirectories and the special case
in getCopyManifestForNativeLibrary in apex.go. However, keeping it calls out
the special treatment of those libraries, and allows a namespace to be added
again if necessary.
Test: Build and boot on taimen_hwasan-userdebug
Test: adb shell /apex/com.android.art/bin/dexdump on taimen_hwasan-userdebug
Test: atest CtsCompilationTestCases on taimen_hwasan-userdebug
Bug: 140734238
Bug: 140790209
Change-Id: Ieb506bfa5d5c159db391273c7eba41d7909de286
"apex_vndk" is a variant of "apex" module.
apex_vndk {
name: "com.android.vndk",
..
}
This rule is used to produce a VNDK APEX per vndk version.
It supports automatic inclusion of vndk libs.
If "vndk_version" property is set, the prebuilt vndk libs of
the version will be included in the apex bundle.
apex_vndk {
name: "com.android.vndk.v29"
vndk_version: "29",
...
}
Otherwise, platform's vndk version is used.
This will replace /system/{lib}/vndk-{ver} and vndk-sp-{ver}.
Bug: 134357236
Bug: 139772411
Test: m com.android.vndk
Change-Id: Ib5c86e625839389670d13c683a7427198ef6852f
native_bridge modules may not have vendor variants because they are
used only for native_loader.
Bug: 140702618
Bug: 137709824
Test: lunch aosp_cf_x86_phone-userdebug && make
Change-Id: Ic9f4abff22597693e66eef520cd1101b5e8c8938
Adds support to Soong for building rust modules. This currently only
supports x86_64 device and x86 linux host targets. The functionality
is sufficient to build crosvm.
Bug: 136189233
Test: Test module builds.
Test: crosvm builds.
Change-Id: I6ea04615834a6d673578ab10ea1a2eb04259fe09
Usually, ".S" files are processes with the c preprocessor, and ".s"
files are not, so they don't have any dependency information, since it
is generated by the preprocessor.
But with the -xassembler-with-cpp flag, ".s" files are processed with
the preprocessor, so we should ask for dependency information from them.
Test: NINJA_ARGS="-t deps out/soong/.intermediates/external/sonivox/arm-wt-22k/libsonivox/android_arm_armv7-a-neon_core_static/obj/external/sonivox/arm-wt-22k/lib_src/ARM-E_filter_gnu.o" m
Test: treehugger
Change-Id: Iee7baeebc2b205b5a2f33e7c1705ea4a5b4fc95a
* changes:
Introduce inject_bssl_hash library property.
BoringSSL FIPS build - introduce extraLibFlags and use for STL libs.
Allow linker scripts when building objects.
Allow .o files as srcs.
Rationale: On non-bionic, stl.go currently adds system libraries to
ldFlags, this causes problems for partialLd rules. However adding the
same libraries to libFlags breaks some existing modules due to symbol
conflicts as the system libraries are linked before some module code.
Introduced a general mechanism for adding libraries to be linked
last rather than making this STL-specific.
Bug: 134581881
Bug: 137267623
Test: TH
Change-Id: I779f28c6586b3fea85cc6299b686e4fde95262d3
When the native coverage is enabled, APEXes (and files there) are built
for native coverage as well.
Bug: 138952487
Test: make -j NATIVE_COVERAGE=true COVERAGE_PATHS='*' com.android.resolv
find out -name "*.gcno" | grep DnsResolver shows files
Test: libnetd_resolv.zip is found under
$(TARGET_OUT)/apex/com.android.resolv/lib directory
Change-Id: I97bcee9bf8ffc0dc71453abbdb613ed56ea2cdb4
This change fixes a problem in sanitizerMutator where a module is linked
with of non-sanitized variant of a lib at build-time, but is linked with
the sanitized variant of the lib at run-time.
This happened because, for each sanitizer type, every shared libs are
split into non-sanitized and sanitized variants, and then either of the
variants are suppressed from Make so that it isn't installed to the
device.
This change fixes the problem by NOT splitting for shared libs; only the
sanitized variant is created if needed. Header libs, static libs and
shared libs for a few sanitizer types (asan/fuzzer) are however split
into two. This is because the static and headers libs become part of the
depending module, and asan/fuzzer require that the depending module and
the dependant module should be compiled for the same sanitizer.
Bug: 138103882
Bug: 138426065
Test: m com.android.runtime.debug
Check that libziparchive exists under both
/system/apex/com.android.runtime/[lib|lib64]
Change-Id: Ia447785c485c0d049e19477b32bc638bfe6f1608
When no-vendor-variant VNDK is enabled,the vendor variant of VNDK
libraries are not installed.This should not be fit for recovery module.
Recovery module deps should be always installed.
Bug: 138812833
Test: `adb reboot recovery;` recovery mode boot ok
Change-Id: I0c3b8ac0fb0176677ddd94ba7216dd068f2eb81b
In `apex.apexBundle.GenerateAndroidBuildActions`, we used to pass the
"all tests" ("") module as `module` for all `apexFile` objects created
from a test module using `test_per_src: true`. An immediate issue of
this situation was that the "" module is hidden from Make, which made
all the generated `apexFile` objects hidden from Make too. This would
break the construction of flattened APEXes, as they rely on Make logic
to install their files.
Instead of collecting `test_per_src` test variations' output files in
`cc.Module.GenerateAndroidBuildActions` and using them in
`apex.apexBundle.GenerateAndroidBuildActions` as part of handling the
"" variation as a direct dependency of an `apexBundle`, process them
as indirect dependencies (and do nothing for the "" variation direct
dependency).
Adjust the indirect dependency logic in
`apex.apexBundle.GenerateAndroidBuildActions` to allow not only
shared/runtime native libraries as indirect dependencies of an
`apexBundle`, but also `test_per_src` tests.
Test: m (`apex/apex_test.go` amended)
Bug: 129534335
Change-Id: I845e0f0dd3a98d61d0b7118c5eaf61f3e5335724
Use Kythe (https://kythe.io) to build cross reference for the Android
source code. ~generate the input for it during the build. This is done
on demand: if XREF_CORPUS environment variable is set, build emits a
Ninja rule to generate Kythe input for each compilation rule. It
also emits two consolidation rules (`xref_cxx` and `xref_java`),
that depend on all Kythe input generation rules for C++ and Java.
The value of the XREF_CORPUS environment variable is recorded in the
generated files and thus passed to Kythe. For the AOSP master branch it is
`android.googlesource.com/platform/superproject`, so the command to build
all input for Kythe on that branch is:
```
XREF_CORPUS=android.googlesource.com/platform/superproject m xref_cxx xref_java
```
Each Kythe input generation rule generates a single file with .kzip
extension. Individual .kzip files have a lot of common information, so
there will be a post-build consolidation step run to combine them.
The consolidated .kzip file is then passed to Kythe backend.
The tools to generate .kzip files are provided by Kythe (it calls them
'extractors'). We are going to build them in toolbuilding branches
(clang-tools and build-tools) and check them in as binaries into master
and other PDK branches:
For C++, `prebuilts/clang-tools/linux-x86/bin/cxx_extractor`
for Java, `prebuilts/build-tools/common/framework/javac_extractor.jar`
Bug: 121267023
Test: 1) When XREF_CORPUS is set, build generates Ninja rules to create
.kzip files; 2) When XREF_CORPUS is set, building
`xref_cxx`/`xref_java` creates .kzip files; 3) Unless XREF_CORPUS is
set, build generates the same Ninja rules as before
Change-Id: If957b35d7abc82dbfbb3665980e7c34afe7c789e
If a test module with a `test_per_src` property set to `true` is
included in an APEX module, add all the variants for mutator
`test_per_src` as dependencies of the APEX module (not just the
first one).
This is done by adding variation "" of mutator `test_per_src` when
adding a test dependency to an APEX module, which creates an indirect
dependency of the APEX module on all the `test_per_src` variants of
the test module. When generating outputs for the APEX bundle, fetch
and include the set of test outputs from the "" variant.
Test: m (`apex/apex_test.go` amended)
Bug: 129534335
Change-Id: I1c99855971a8a9b2fc5b964a420e882b6791d4e6
Have `cc.testPerSrcMutator` create an additional variation named "",
having no sources (and generating no output file), but depending on
all other `test_per_src` variations and collecting their output files
in a new field named `cc.Module.testPerSrcOutputFiles`. This is useful
in the case where a module depends on all the `test_per_src`
variations of a test module.
Test: m
Bug: 129534335
Change-Id: I905decc0b9417f47cee9113466677d3bb61ad7b6
Needed to allow removal of the include_dirs property from the
asm_defines.s module. Also, adds ObjectLinkerProperties to cc_defaults
so that default settings of header_libs are correctly prepended to the
properties in cc_object.
Bug: 35624006
Test: m cpp-define-generator-asm-support - compare output before and after change
Change-Id: Ib95d79c5eba4a89b7ab04b6c62090b720ec7e9fe
Bug: http://b/134177005
Bug: http://b/116873221
Previously, the libprofile-extras dependency was added as a
LateStaticLib and the constructor in this library was included during
linking with the '-uinit_profile_extras' linker flag. This was done
because at the deps() stage, the exact binaries that need coverage are
not known (in fact the coverage-enabled variants are not created yet).
This meant that for a link command, if one of the shared libraries
already exported the constructor, the output of the link command did not
load/link libprofile-extras.
For other reasons, we now want to add more symbols to this library that
need to be linked into all libraries and executables. To accomplish
that, refactor the dependency handling so libprofile-extras can be added
as a 'WholeStaticLib'.
This is done by creating a new dependency type (with a coverageDepTag
dependency tag) to add libprofile-extras as a dependency for all modules
that can potentially link with coverage. During the flags() call, this
dependency is moved as a WholeStaticLib dependency iff coverage is
enabled in this link step.
There are a few NFC changes as well:
- deps() takes a DepsContext parameter.
- flags() has an extra PathDeps parameter and return value.
- add useSdk() helper to cc.Module.
Test: Build with coverage and check that we can generate coverage using
SIGUSR1 and the debug.coverage.flush sysprop.
Change-Id: I7e7d8201956a150febbda5bb1794f8ece016db8b
This commit enables ABI diff for libraries without source.
Stub libraries are excluded.
Test: ./create_reference_dumps.py -products aosp_arm64
Test: make
Bug: 135728451
Change-Id: Idbe276db6f5e057175fc098f0226cb38996faa17
sanitizerRuntimeDepsMutator only modifies the currently visited
module, it can visit modules in parallel.
Also, stop recursing into modules that are not static dependencies,
and stop recursing if the module already has all modifications that
the mutator could make.
Test: m checkbuild
Change-Id: I95a57f763a91940f1854ba3c587a2f70e8baba97
* changes:
Consolidate *MutatorContext and ModuleContext into BaseModuleContext
Add test for missing defaults modules with AllowMissingDependencies
Capture missing dependency error rules
Share buildDir for android/soong/android tests
Reimplement AddMissingDependencies
Add GenerateAndroidBuildActions to DefaultsModuleBase
Exported includes have been maintained along with other C/C++ flags.
This makes dependencies unclear, and users have had to parse flags to
get exported directories. This separates exported includes and
exported flags, thus making data more structured and explicit.
Bug: 132818174
Test: m
Change-Id: I5c25ac2224988c4a67e4db6fd6e4d39090b74041
Add an empty GenerateAndroidBuildActiosn to DefaultsModuleBase
so that every defaults module doesn't need to provide one. This
will also allow adding an implementation in the next patch.
Test: m checkbuild
Change-Id: I13554bdb3a287c2f18e1efab74d4f08a1ba8620c
blueprint.BaseModuleContext is the set of methods available to all
module-specific calls (GenerateBuildActions or mutators). The
android package split the same functionality across baseContext (nee
androidBaseContext), BaseModuleContext, and BaseContext.
Consolidate all of them into android.BaseModuleContext.
Test: m checkbuild
Change-Id: I2d7f5c56fd4424032cb93edff6dc730ff33e4f1e
There are cases where a module needs to refer to an intermediate
output of another module instead of its final output. For example,
a module may want to use the .jar containing .class files from
another module whose final output is a .jar containing classes.dex
files. Support a new ":module{.tag}" format in any property that
is annotated with `android:"path"`, which will query the target
module for its ".tag" output(s).
Test: path_properties_test.go, paths_test.go
Test: no unexpected changes in build.ninja
Change-Id: Icd3c9b0d83ff125771767c04046fcffb9fc3f65a
- Updates the fuzzer builds to use SANITIZE_TARGET='fuzzer' instead of
'coverage'.
- Removed an old dependency that made fuzzer builds without ASan
an error.
- Fixed up the build flags to allow fuzzers to be built. Previously, the
coverage flags were manually provided. As the toolchain has moved on,
these flags are no longer compatible with libFuzzer, and so I've updated
them to use the correct, compatible flags.
- Added a dependency mutator for fuzzer coverage.
Bug: 121042685
Test: With all patches in the bug merged, build a fuzzer using
'SANITIZE_TARGET=fuzzer mmma <your_fuzzer>'.
Change-Id: Ib6246980f77bc4babe587b1e88038aa12228fa83
Merged-In: Ib6246980f77bc4babe587b1e88038aa12228fa83
This fixes the problem with cc_object not having this suffix and
as a result overriding non-bridged variants for modules using mk files.
Bug: http://b/77159578
Test: build 4arch product
Change-Id: Ie958f997c6f54f93d8b2987ca5ba605004e1eb70
Do not rely on 'module.Name()' to decide VNDK link type.
Some prebuilt modules such as libclang_rt_prebuilt_library_shared and
vndk_prebuilt may have different naming schemes.(prefix/suffix)
And llndk_library module has '.llndk' suffix.
Instead, use VNDK-related properties (e.g. vndk.enabled,
vendor_available, etc.).
Bug: 132800095
Test: m & check LOCAL_SOONG_LINK_TYPE for prebuilts
Change-Id: I06b0c182aeab16969c44a86397f02be4beb80bbd
For vndk_prebuilt_shared module, it is set by 'version' property.
For other vndk libs(e.g. cc_library with vndk.enabled), it is set as
PLATFORM_VNDK_VERSION.
Background:
To support "skip installing current VNDK".
You can get a system.img without current VNDK libs.
This may help when you want a smaller system.img given that the image
will be used with a specific version (not current) of vendor image.
Bug: 132140714
Test: m TARGET_SKIP_CURRENT_VNDK=true && see if current VNDK is not
installed
Change-Id: I1c603efc3e95fe8bdf870f2de91994077899fca7
When HWASAN is enabled, the runtime is conceptually part of Bionic (and
mutually depends on it), so it needs to be treated in the same way as the
Bionic libs.
Now there are only two copies of the runtime: the one in
/system/lib64/bootstrap (which won't be used by ordinary processes) and the
one in the runtime APEX.
This reduces the size of the HWASAN system image and fixes an issue where
multiple copies of the HWASAN runtime were being loaded into 64-bit binaries in
APEXes because the linker namespace for the binary is different from the one
for its dependent libraries outside of APEXes. HWASAN only supports loading
one copy of the runtime per process, so this was causing such binaries to
crash on startup.
Change-Id: I228896e193a035e6dfba9f6e28d0b2e12fc163ea
This is the first commit to generate VNDK snapshot with Soong: .so
files, some txt files, and notice files are captured with Soong. As
ld.config.txt is currently in Android.mk and will be deprecated soon,
configs files (and zipping all of artifacts) are still handled with
Makefile.
Bug: 131564934
Test: 1) DIST_DIR=out/dist development/vndk/snapshot/build.sh
Test: 2) try installing vndk snapshot with:
development/vndk/snapshot/update.py
Change-Id: I8629e1e25bfc461fd495565bb4872c9af176cf92
This allows us to build guest libraries for the native bridge for
arm/arm64 architectures.
Bug: http://b/77159578
Test: make
Change-Id: I35520ca456105ddadd456c78a4eb1e6de39147c5
This commit allows a module to opt in for ABI checks even when it is
not an LLNDK/VNDK module.
Bug: 131421213
Test: Add `header_abi_checker { enabled: true, }` to some module
Change-Id: Ie09d262e651cbb44d7d0eba652f55dc1e1e52962
So that <module>/gen/yacc/... is (re)created by a single rule, previous
files are removed, and location.hh is in the build graph when it is
produced.
Test: treehugger
Change-Id: I2f6e47ea07f315e10ae1cb8ad50697e7123d0285
Add a proto.plugin property to allow specifying a custom protoc
plugin to generate the code.
Fixes: 70706119
Test: m am StreamingProtoTest
Change-Id: I1ecdd346284b42bbcc8297019d98d2cd564eb94c
Using blueprint.Rule for protoc commands was causing code duplication
because there was no good way to run the same protoc for cc, java and
python but then run custom source packaging steps for java and python.
Move most of the code into a common function that returns a
RuleBuilder, and then let java and python add their own commands at
the end of the rule.
Bug: 70706119
Test: All Soong tests
Test: m checkbuild
Change-Id: Ic692136775d273bcc4f4de99620ab4878667c83a
Bug: http://b/128524141
Include libprofile-extras (defined in system/extras/toolchain-extras) to
all modules that need a coverage variant. Also add
'-uinit_profile_extras' when linking with coverage. This causes the
setup code in libprofile-extras to be linked into binaries/libraries
with coverage enabled.
We add the static library to the non-coverage variants as well but is a
no-op for them (since the '-u...' flag is not added for them).
Adding this dependency creates several circular dependencies since
coverage variants were being created for other module types that never
had any compilation or linking done during the build. This change stops
creating coverage variants for toolchain_library, cc_prebuilt_library_*,
cc_library_headers module types (by adding a function to the linker
interface to specify whether native coverage is enabled).
Test: m NATIVE_COVERAGE=true COVERAGE_PATHS=*
Test: blueline_coverage target in internal branch (using forrest)
Change-Id: I5db876eb953639a55ba007248dd24e497f987730
Added synopsis to the following modules under cc package:
* cc_binary
* cc_binary_host
* cc_defaults
* cc_genrule
* cc_test
* cc_test_host
Bug: b/128337482
Test: Generated the documentation and verified that the
synopsis was added to each of the module.
Change-Id: I23b7eda449c340783d7cc592df5d2bd399255bf9
When no-vendor-variant VNDK is enabled, the vendor variant of VNDK
libraries are not installed. Since not all VNDK libraries will be
ready for this, we keep a list of library names in cc/vndk.go to
indicate which libraries must have their vendor variants always
installed regardless of whether no-vendor-variant VNDK is enabled.
Also add --remove-build-id option to the strip script to facilitate
the check of functional identity of the two variants.
Bug: 119423884
Test: Add a dummy VNDK library and build with
TARGET_VNDK_USE_CORE_VARIANT := true, with the corresponding
build/make change.
Change-Id: Ieb1589488690e1cef1e310669a8b47a8b8759dac
This change creates following symlinks for bionic files.
/system/lib/libc.so -> /apex/com.android.runtime/lib/bionic/libc.so
/system/lib/libm.so -> /apex/com.android.runtime/lib/bionic/libm.so
/system/lib/libdl.so -> /apex/com.android.runtime/lib/bionic/libdl.so
/system/bin/linker -> /apex/com.android.runtime/bin/linker
...
This allows us to not have mountpoints under /bionic.
Bug: 125549215
Test: m and inspect the symlinks in the system partition.
Change-Id: I3a58bf4f88c967862dbf06065a1af8fc4700dda3
Vendor-available libs can be double-loaded if LLNDK libs depend
on them. Currently soong checks only 'direct' dependency bewteen
LLNDK and VNDK lib. With this change, soong checks if every dependencies
from LLNDK is also LLNDK or VNDK-SP or marked as 'double_loadable:true'.
This change causes many libs to be marked as 'double_loadable'.
Bug: 121280180
Test: m -j
Change-Id: Ibc1879b6fd465a3141520abe0150018c3051c0a7
When a sysprop module is listed in whole_static_libs, it is renamed to
"lib" + <module> to actually refer to the generated C++ library for the
sysprop module.
Test: m (sysprop_test amended)
Change-Id: I05eddb24433d444376787be567830929ef078159
Bug: http://b/116873221
This allows us to enable coverage for a module (typically static
libraries) even if a dependent module cannot build with coverage. In
this case, the dependent module can just pick the variant with coverage
off.
- Create the following variants from the coverage mutator:
- "" (empty): Don't build with coverage and always pick the
non-coverage variants for dependents. This variant is
created for modules with 'native_coverage: false'.
- "cov": If this module's path is covered by the COVERAGE_PATHS
option, build this module with coverage. If not, build
this module without coverage. In either case, pick
coverage variants ("cov") for dependencies if available.
- Do not enable coverage:
- for NDK stub libraries
- if sdk_version < 23 since libc doesn't export 'stderr' which is
needed by the coverage/profile runtime library.
- for VNDK libraries
Test: In AOSP: m COVERAGE_PATHS=system/security NATIVE_COVERAGE=true nothing
Change-Id: I4d08790d35cdeaf12fb3c4f999d69a870e65836a
A newly introduced sysprop_library soong module will generate a
java_sdk_library and a cc_library from .sysprop description files.
Both Java modules and C++ modules can link against sysprop_library
module, thus giving consistency for using generated sysprop API.
As Java controls accessibility of Internal / System properties with
@hide and @SystemApi, 2 different header files will be created. And
build system will selectively expose depending on the property owner
and the place where the client libraries go into.
Bug: 80125326
Bug: 122170616
Test: 1) Create sysprop_library module.
Test: 2) Create empty txt files under prebuilts/sdk.
Test: 3) Create api directory, make update-api, and see changes.
Test: 4) Try to link against sysprop_library with various clients.
Test: 5) Soc_specific, Device_specific, Product_specific, recovery flags
work as intended.
Change-Id: I78dc5780ccfbb4b69e5c61dec26b94e92d43c333
cc.Module.staticVariant is used to track the corresponding static
variant of a shared variant. This change fixes a problem that the
staticVariant field is not correctly set when the lib is with stubs:
{...}. This was happening because the staticVariant was set by adding
dependency from shared variant to static variant to reuse object files.
However, for a lib with stubs, the dependency was not created because it
does not make sense to share object files for stubs lib where source
code is auto-generated.
Fixing the issue by adding dependency to the static variant with a
different dependency tag whose only purpose is to set staticVariant
field.
Bug: 122885634
Test: m (cc_test amended)
Change-Id: I7f97cbb4c4a28bf9a93839d3b91ee140835aa6af
Otherwise the code after this assumes that the "to" library is an NDK
library and panics when it isn't.
Bug: 124019854
Test: trigger error, no longer see panic
Change-Id: I88d10e8d882285e24b4f42d0cf85c2d658348617
relative_install_path for cc_library is respected by APEX.
relative_install_path for cc_binary is not yet respected because doing
it will break the path to the dynamic linker in the runtime APEX.
That change should be done along with changes in init, bionic, etc.
Bug: 123721777
Test: m (apex_test.go amended)
Change-Id: I855f8eda0d4255d563861ac96d0d3e2c669e9a2a
Add an empty DepsMutator to ModuleBase so it doesn't have to be
implemented on every module that doesn't need it.
Test: all soong tests
Change-Id: I545a832a0dbf27386d3080377a75ea482cd9ce59
If the bootstrap property is set to true, a binary configured to refer
to the bootstrap linker at /system/bin/bootstrap/linker[64]. This is for
very early processes that are executed before the init makes the linker
by bind-mounting it.
Bug: 120266448
Test: m init_second_stage and use readelf on the built file
DT_INTERP is set to /system/bin/bootstrap/linker64 and
Change-Id: I67487701192f127679cc8127ddc9f53e102ba9c4
This change fixes a bug that sanitizer runtime libs for non-core variant
(e.g. recovery, vendor, etc.) are not installed. It happened because the
dependency to the sanitizer runtime lib was without 'image' variant,
which in most case caused only the core variant - which is the first in
the image variants - of the lib to be installed.
Fixing the issue by correctly selecting image variant depending on the
location of the lib having dependency to the runtime lib.
Bug: 123525879
Test: SANITIZE_TARGET=hwaddress m out/target/product/blueline/boot.img
Test: SANITIZE_TARGET=address m out/target/product/blueline/boot.img
libclang_rt.*.so is under
out/target/product/blueline/root/recovery/system/lib64
Change-Id: Iea7d718d4971e36521f0a3f712a454de944cd7ac
Some modules rely on symlink_preferred_arch to have expected files
present. This change makes apexs include these symlinks.
Test: m com.android.runtime.debug
pushd $(mktemp -d)
mkdir mnt
unzip $OUT/apex/system/com.android.runtime.debug.apex
sudo mount -o loop,ro apex_payload.img mnt
Ensure that mnt/bin/dalvikvm and mnt/bin/dex2oatd both exist and
are symlinks to mnt/bin/dalvikvm64 and mnt/bin/dex2oatd32
respectively.
Bug: 119942078
Bug: 122373634
Bug: 123079311
Change-Id: I47868fbedc5bdd3141a836c488f79e91e0a6ddfe
Add a dependency from a stubs lib to headers libs so that the headers
can be re-exported.
Bug: 122717287
Test: m; a test added to apex_test.go
Change-Id: I8d48c072815c6b02d343ef09cb44dfc6d1af8e64
A module can be built multiple times when it is referenced from one
or more APEXes. Sometimes, it is required for the module to behave
differently depending on the context; e.g., do A when built form
APEX M, do B when built for APEX N, and do C when built for platform.
The idea is to have a macro __ANDROID_APEX__ which is set to the
name of the apex that the module is built for. It is undefined when
the module is built for platform.
Bug: 122714993
Test: m (apex_test amended)
Change-Id: I11a89c6a0e799f4810194de7ef9ee472a71ca498
Introduce a new tag earlySharedDepTag which is added in front of the
ordinary sharedDep dependencies. Dependency to the ASAN runtime lib is
added with the new tag.
Bug: 120894259
Bug: 121038155
Test: m; SANITIZE_TARGET=address m
Use readelf -d to see if the runtime lib is in the first DT_NEEDED one.
Change-Id: I90de6ab95df734a99995532d826564b13fe05316
This CL adds configs for the arm64 and x64 fuchsia
device targets, sets up the necessary linker flags,
and disables some functionality that is not currently
supported on Fuchsia.
Bug: 119831161
Test: Compile walleye, internal validation against
fuchsia_arm64-eng and fuchsia_x86_64-eng.
Change-Id: I2881b99d2e3a1995e2d8c00a2d86ee101a972c94
This commit fixes `shared_libs` for `cc_prebuilt_binary`,
`cc_prebuilt_library_static`, and `cc_prebuilt_library_shared`. Before
this commit, all shared libraries in `shared_libs` are dropped from the
generated `LOCAL_SHARED_LIBRARIES`. This commit fixes the problem by
delegating `linkerDeps()` to `libraryDecorator.linkerDeps()`.
This commit also fixes the dependencies to NDK shared libraries. Before
this change, those dependencies are mapped to a `ndkStubDepTag` and then
ignored by the computation of `AndroidMkSharedLibs`. This commit adds
it back.
Bug: 123053270
Bug: 119084334
Test: libclang_rt.scudo-*.so can be checked with 2 more hacks.
Change-Id: I59e37e1a3fe0c329e8cb7032e5671f117f7832a0
libclang_rt.*.so depends on libc++, which is not a part of NDK. Thus,
this workaround must be added in order not to break the build when the
prebuilt dependencies are checked.
Bug: 121358700
Test: make checkbuild
Change-Id: Icaeb7adf96fb72829053e198b659ebcb19a035fc
This commit removes a break statement so that apex stub libraries are
added to LOCAL_SHARED_LIBRARIES for prebuilt ABI checker.
This CL doesn't change I09b78e38df285033ef6e9c85f7ea4b0274e85070 [1].
The libraries provided by apex modules are not installed to
`/system/lib[64]` because their stub libraries have
`LOCAL_UNINSTALLABLE_MODULE := true`.
[1] https://android-review.googlesource.com/844555
Bug: 120266448
Bug: 119084334
Test: Add `stubs: { symbol_file: "libnetd_resolv.map.txt", versions: ["1"]}`
to libnetd_resolv, create a program that depends on
`libnetd_resolve`, build the program, and do not find
`/system/lib/libnetd_resolv.so`.
Change-Id: Iffa2c1a0eac9c4940ec1fa05fbacb9806272c31e
This commit skips the ABI checks on LL-NDK-Private because
LL-NDK-Private libs are only used by other VNDK-core or VNDK-SP libs on
the system partition, are NOT used by vendor modules, and do not
constitute a system-vendor interface.
Bug: 122938657
Test: development/vndk/tools/header-checker/utils/create_reference_dumps.py
Change-Id: Ia2af4250ef1443f8ea3ed5ab111668462f120979
This change first introduces the interface "Sanitizeable" that
module types other than cc.Module can use to be handled by the sanitizer
mutator. APEX module, by implementing the interface, gets sanitizer
variants.
In doing so, sanitizer.go is refactored so that modules have explicit
dependencies to the runtime sanitizer libraries. This allows the runtime
library to be packaged into the APEX when required. This also completes
the dependency graph; updating the prebuilt sanitizer runtime will
trigger rebuilding of modules using the runtime.
Bug: 120894259
Bug: 121038155
Test: SANITIZE_TARGET=hwaddress m apex.test
Test: TARGET_FLATTEN_APEX=true SANITIZE_TARGET=address m
Change-Id: Ia91576ff48cda3c996350308b75bf83fcf7c23d7
This reverts commit 769e50b3c9.
Reason for revert: Likely causing build failure on aosp_x86_64-eng in aosp_master:
"build/make/core/base_rules.mk:271: error: art/build/apex: MODULE.TARGET.SHARED_LIBRARIES.com.android.runtime.host.libart-compiler already defined by art/build/apex."
Change-Id: I83b7caa04b2648e4e4914aae2fa5878516634eed
The unstripped file for libraries in APEXes are available via
out/target/product/<device>/symbols/apex/<apex_name>/path_to_lib.
This change make the symbol files available by installing the individual
files in APEXes to the directory where the APEXes will be mounted at
(i.e. runtime directory which is /apex/<apex_name>). Note that the files
are not actually packaged to a filesystem image; they are installed just
to create the symbol files under the out directory where developers can
use them for debugging.
Bug: 120846816
Test: m com.android.runtime.debug
There are unstripped files under
out/target/product/walleye/symbols/apex/com.android.runtime.debug
Change-Id: Ib182e2bf8787b7669ccba13814491db35370f468
If a lib is directly included in an APEX (via native_shared_libs
property) and the lib has stubs (via stubs.versions property), then the
ordinary non-stubs variant of the library is renamed to
<libname>.bootstrap in the makefile. At the same time, the stubs variant
of the lib becomes visible and it's name is <libname>.
This ensures that modules in Android.mk build against the stubs
variant thus preventing them from using private APIs in the lib.
The non-stubs variant, however, is used if the module explicitly has
set the new 'bootstrap' property to true. This is useful for building
some early binaries (such as init and vold) which need to run before
APEXes are activated. Since they can't use the bionic libs from the
runtime APEX, they should use the bionic libs left in the system
partition which is called the boostrap bionic.
Bug: 120266448
Test: m
Test: m with https://android-review.googlesource.com/c/platform/bionic/+/849044
Change-Id: I882b8aeb5b29460f07b4424e4f8eb844d6c9a9b0
This commit stops building lsdump files for APEX variants since APEX
variants are local to APEX modules themselves.
Bug: 121986692
Test: make findlsdumps # compare $ANDROID_PRODUCT_OUT/lsdump_paths.txt
Change-Id: I37fcd152d0d84d235a354ea53e53e808dd71464a
This change fixes following problem:
1) a native lib having stubs is defined.
2) the lib is included in an APEX.
3) a static binary is linking the lib from outside of the APEX.
4) then, the dependency from the binary to the lib is vanishing.
This is happening because cc.depsToPaths() mistakely does not
distinguish static lib deps from shared lib deps. For shared lib deps,
it creates two dependencies (one for stubs variant and the other for
non-stubs variant) and choose the stubs variant when the lib and the
current module is not in the same APEX (i.e. dependency to the non-stubs
variant is discarded). However, since we don't have stubs variant for
static library, it ends up having no dependency to the library if the
link is static.
Fixing the issue by skipping the variant selection routine when the link
is static.
Test: m (apex_test added)
Test: build with https://android-review.googlesource.com/c/platform/bionic/+/849044
Change-Id: I21102a31cc5c0b105da2affdd035bd5cc571a6ab
use_vendor, when set to true, brings vendor variant of the native
libraries and binaries to the APEX.
Bug: 115707625
Test: m (apex_test updated)
Change-Id: Ib4e996f8652f4ce4645a9c22f6914e2ab35edda6
The runtime APEX is built for host as well as for target. Therefore
stubs libs should be available also for host.
Bug: 120670568
Test: follow the repro step shown in b/120670568#comment4
Change-Id: I350fe490848ae9ceb55aade0521bdfaf48ed083f
This change fixes a problem that APEX variations are created for the
modules that actually shouldn't built for any APEX. For example,
consider this case.
apex { name: "myapex", native_shared_libs: ["mylib"],}
cc_library { name: "mylib", shared_libs: ["libfoo#10"],}
cc_library { name: "libfoo",
shared_libs: ["libbar"],
stubs: { versions: ["10"], }, }
cc_library { name: "libbar", ...}
Before this change, both the stubs and non-stubs variations of libfoo
were mutated with apexMuator, which is incorrect for the non-stubs
varia; there is no dependency chain from the apex "myapex" to the
non-stubs variation, but to the stubs variation due to the #10 syntax.
This was happening becauses we used the name of the module to determine
whether it should be built for APEX or not. Both stubs and non-stubs
variations have the same module name "libfoo".
Fixing this issue by recording the list of APEX variations required
directly on the module. So, the stubs variation of libfoo has myapex in
its apex variations list, but the non-stubs variation doesn't, and thus
apexMutator does not pick up the non-stubs variation.
Test: m (apex_test updated and passing)
Test: cherry-pick ag/5747464 and m
Change-Id: I31e618626809a828a55fff513ef5f81f79637afa
When the stubs variant of a library is dependend by a platform component
and the library is included in one or more APEX, the library is not
installed to the platform, because it is provided by APEX.
Bug: 120266448
Test: m
Test: add stubs: { versions: ["1"], }, to libnetd_resolv
then build netd. libnetd_resolv.so does not exist under /system.
Change-Id: I09b78e38df285033ef6e9c85f7ea4b0274e85070
When a native module is built for an APEX and is depending on a native
library having stubs (i.e. stubs.versions property is set), the stubs
variant is used unless the dependent lib is directly included in the
same APEX with the depending module.
Example:
apex {
name: "myapex",
native_shared_libs: ["libX", "libY"],
}
cc_library {
name: "libX",
shared_libs: ["libY", "libZ"],
}
cc_library {
name: "libY",
stubs: { versions: ["1", "2"], },
}
cc_library {
name: "libZ",
stubs: { versions: ["1", "2"], },
}
In this case, libX is linking to the impl variant of libY (that provides
private APIs) while libY is linking to the version 2 stubs of libZ. This is
because libY is directly included in the same apex via
native_shared_libs property, but libZ isn't.
Bug: 112672359
Test: apex_test added
Change-Id: If9871b70dc74a06bd828dd4cd1aeebd2e68b837c
VNDK libs are system defined libraries. They must not be product
specific. Adding sanity check and a test to prevent setting
`product_specific: true` on VNDK libs.
Bug: 119575107
Test: building a vndk lib with 'product_specific: true,'
must return error.
Change-Id: Ie0326540a692573f076ee08baf5d2e2f09d1007e
AArch64 execute-only memory is only supported when using lld as the
linker. There's still a few modules which don't use lld, so in those
cases we need to disable this option.
Bug: 77958880
Test: Module with use_clang_lld false builds without XOM
Test: Module without use_clang_lld defined builds with XOM
Change-Id: I4ab961c4d7342c54c6b40b9facfe18a45ed883bd
Before it just mentioned 'double_loadable', but in this context,
LL-NDK and VNDK-SP libraries also work.
Bug: 119790516
Test: N/A
Change-Id: Ie09a959fd5e05b9cb73db30d3cc2853694577dfe
Adds build system support for generating AArch64 binaries with
execute-only memory layouts via a new xom module property. Also adds
support for an ENABLE_XOM build flag for global builds.
Bug: 77958880
Test: make -j ENABLE_XOM=true
Change-Id: Ia2ea981498dd12941aaf5ca807648ae37527e3ee
Shadow call stack (SCS) is a security mitigation that uses a
separate stack (the SCS) for return addresses.
The effect of setting sanitize.scs on a shared library is to build
the library and all of its static library dependencies with SCS. This
is similar to CFI and the other sanitizers.
Bug: 112907825
Bug: 119557795
Change-Id: I82fb2b38b10eac911c4d2d120b74fea4af0622ad
This reverts commit 555c114283.
Reason for revert: The namespace issue in the pi-dev-plus-aosp-without-vendor branch is now fixed.
Change-Id: I26ed591447797a8ee505f43bdd209162418b6c5e
Arch property struct types are created at runtime. Go has a limit
of 2**16 bytes for the name of a type, and the type of a struct
created at runtime is a string containing all the names and types
of its fields. To avoid going over the limit, split the runtime
created structs into multiple shards.
Also undo MoreBaseLinkerProperties now that it is no longer
required.
Bug: 80437643
Test: m checkbuild
Test: no change to out/soong/build.ninja
Change-Id: I035b20332ec63f3d4b1696855c5b0b0a810597b7
llvm-ar takes a --plugin argument but it is ignored for compatibility,
so passing it has no effect.
Change-Id: I4fc51d226d66cf2a43462d3d4ccc12e6e5ebb226
Export static libraries through LOCAL_STATIC_LIBRARIES and
LOCAL_WHOLE_STATIC_LIBRARIES. This enables dependency-based NOTICE file
generation. Also, add a notice property in the libwinpthread module.
Bug: 36073965
Test: cc_test.go
Change-Id: If1ca1f9159e80cf8fbe71df7a13ca5d6a1f63b40
Export static libraries through LOCAL_STATIC_LIBRARIES and
LOCAL_WHOLE_STATIC_LIBRARIES. This enables dependency-based NOTICE file
generation. Also, add a notice property in the libwinpthread module.
Bug: 36073965
Test: cc_test.go
Change-Id: Ic63ca523b40acac82bbe876f7aa40ecd495907c5
A cc_library or cc_library_shared can be configured to have stubs
variants of the lib.
cc_library_shared {
name: "libfoo",
srcs: ["foo.cpp"],
stubs: {
symbol_file: "foo.map.txt",
versions: ["1", "2", "3"],
},
}
then, stubs variants of libfoo for version 1, 2, and 3 are created
from foo.map.txt. Each version has the symbols from the map file where
each symbol is annotated with the version that the symbol was introduced
via the 'introduced=<ver>' syntax. The versions don't need to be in sync
with the platform versions (e.g., P for 28). The versions are local to
the library.
For another library or executable to use the versioned stubs lib, use
the new 'name#ver' syntax to specify the version:
cc_binary {
name: "test",
....
shared_libs: ["libFoo#2"],
}
Internally, a new mutator 'version' is applied to all cc.Module objects.
By default, a variant named 'impl' is created for the non-stub version.
If the versions property is set, additional variations are created per a
version with the mutable property BuildStubs set as true, which lets the
compiler and the linker to build a stubs lib from the symbol file
instead from the source files.
This feature will be used to enforce stable interfaces among APEXs. When
a lib foo in an APEX is depending on a lib bar in another APEX, then bar
should have stable interface (in C lang) and foo should be depending on
one of the stubs libs of bar. Only libraries in the same APEX as foo can
link against non-stub version of it.
Bug: 112672359
Test: m (cc_test added)
Change-Id: I2488be0b9d7b7b8d7761234dc1c9c0e3add8601c
In order to simplify the wrapper function, and stop using a linker
script, generate a set of flags to pass to LLD. Then run
host_bionic_inject on the linked binary in order to verify the
embedding, and give the wrapper function the address of the original
entry point (_start).
Bug: 31559095
Test: build host bionic with prebuilts/build-tools/build-prebuilts.sh
Change-Id: I53e326050e0f9caa562c6cf6f76c4d0337bb6faf
ApexModule is the interface for APEX-aware modules. The module type apex
uses the interface to get APEX-specific information from other modules,
such as the list of APEXs that a module should be built for.
A module that is included in an APEX will be built specificaly for the
APEX. This is especially required for shared libraries; we shouldn't
just copy the artifacts built for platform, because they may be linking
against private (=unstable) symbols that are not available to APEXs
which are basically unbundled.
This CL, as a first step, makes cc.Module an APEX-aware module type.
Bug: 112672359
Test: m apex.test; the built apex has all the direct and transitive
shared lib dependencies of the libs and executables listed in Android.bp
Change-Id: I21f6a586654779984f0f5154b2a08b2adbf2168b
Clang is always used now, so we can remove all the GCC checks. Removing
GCC-specific configuration will happen in the next CL.
Test: m
Change-Id: I4835ecf6062159315d0dfb07b098e60bff033a8a
JNI testing will need to create basic native shared library
modules, export the minimum mutators and module types for
the required dependencies of a native shared library.
Bug: 80095087
Test: cc_test.go
Change-Id: Ibe7bc88b69cb0851291cb09a4c0c6cdb421b8651
prefer32 needs to be set differently for app and native modules.
Make it use lambda provided by the module type instead of trying
to make archMutator figure it out.
Test: m checkbuild
Change-Id: Ibf8af35fdd3e1721725539d1f5452f4439d2125c
APEX needs to know the location of the output file of cc.Module to copy
it to an intermediate directory and package there.
Bug: 112672359
Test: m apex.test
Change-Id: Iaa19b29c2859df96f50716001dbd57df3f596050
Export Soong cc modules to Make using a new soong_cc_prebuilt.mk that
bypasses all of prebuilt_internal.mk, dynamic_binary.mk and binary.mk.
This also means that stripping is handled in Soong instead of Make.
Relands If9008c50920779048480f5eeeb0084f26006c998 with fixes for
mac builds.
Bug: 113936524
Test: m checkbuild
Change-Id: I9710ff57f0793f36eb889eabd08bd60a365a88dd
Export Soong cc modules to Make using a new soong_cc_prebuilt.mk that
bypasses all of prebuilt_internal.mk, dynamic_binary.mk and binary.mk.
This also means that stripping is handled in Soong instead of Make.
Bug: 113936524
Test: m checkbuild
Change-Id: If9008c50920779048480f5eeeb0084f26006c998
We need to keep support in Soong until toolchain_library no longer uses
GCC.
Test: out/build-aosp_arm64.ninja is the same before/after
Test: build_test on downstream branches
Change-Id: Ib78bcd6d5544afc3a3164f65fa72a3f08b2acf29
This commit extends ABI stability checks to all NDK shared libs
(including the framework-related ones such as libandroid.so).
Bug: 112404572
Bug: 79576032
Test: make findlsdumps # (and check the output)
Change-Id: I0147c60ce0c90d187f85b996911d98326a0c37ae
Dependencies of disabled modules may not have the right variations
for calling AddVariationDependencies, skip DepsMutator completely
on disabled modules.
Bug: 112707915
Test: m checkbuild
Test: prebuilts/build-tools/build-prebuilts.sh
Change-Id: I702e591437e5e6eb9f91f3b7eb32bacc4bd5d249
ctx.AddDependency will succeed if the named dependency only has a
single variant, even if that variant is the wrong architecture.
Use ctx.AddVariationDependency(nil, ...) instead, which requires
that all variations of the calling module match the dependency.
Bug: 112707915
Test: no change to out/soong/build.ninja
Test: using a device dependency in a host java module is an error
Change-Id: I70b661a57d4412eb63b8c9841febfb756e9e025d
This CL fixes a bug that when a module is configured as 'vendor: true' &&
'recovery_available: true', the link type of the recovery variant of the
module is incorrectly set to 'native:vendor'. This was because,
androidmk.go emits 'LOCAL_PROPRIETARY_MODULE := true' whenever
Proprietary property is set to true, regardless of whether it is a
recovery variant or not. This in turn makes LOCAL_USE_VNDK := true for
the module which in turn causes the link type to be 'native:vendor'.
Fixing the bug by resetting the properties like Proprietary, Vendor,
Soc_specific, etc. for the recovery variants.
Bug: 113277544
Test: m -j (test added)
Change-Id: I5d6ae76e46ef8fcd9204d386d0809862a7b0ff7e
This is a new sanitizer similar to ASan, but with a few differences
from the build system perspective:
* Only runs on AArch64.
* Supports static binaries.
* Bionic itself will be built with HWASan.
* Does not have any "if a library is sanitized than the binary must
be, too" requirements unlike ASan. Even better, individual static
libraries can be freely sanitized or not. We propagate "nosanitize"
from binaries to static libraries anyway, because otherwise there
is no good way to disable hwasan on a binary as a whole.
Same a CFI, we export a list of sanitized static libraries to make.
In fact, we export separate lists for vendor and regular libraries,
because it is possible for one to be sanitized without the other
(i.e. there can be mylib.hwasan.vendor w/o mylib.hwasan or vice
versa).
Bug: 112438058, 112709969
Test: manual, part of a bigger patch set
Change-Id: Ie4fdeb522ac03cf9684526882e84dfee3807b6a7
Most everything in Soong is using clang (and we're getting very close
for Make as well), so remove the ability to select GCC to build a
module.
We still need to keep the internal functionality around to find libgcc.a
and other toolchain_library modules with GCC.
Test: m blueprint_tools
Change-Id: I5ef3e3836b9ad3e160669ac32aee39698c9b72c3
This commit cleans up `createVndkSourceAbiDump()` and renames it to
`shouldcreateVndkSourceAbiDump()`.
Test: lunch aosp_walleye-userdebug && make
Change-Id: Iff4379e2812c4b5c5baff288b938eed5d92e024f
Fixed a bug that recovery variant of a module is not created on 32-bit
targets. The bug was happening because the creation of the recovery
variant relied on DevicePrefer32BitExecutables() which returns false
for 32-bit only targets.
Now, recovery variant is checked against the primary architecture of the
device that is returned by DevicePrimaryArchType().
Test: m -j adbd.recovery on aosp_arm and aosp_arm64
adbd is built under recovery/root/system/bin and it is ELF32 and ELF64,
respectively for the targets.
Test: m -j libc.recovery on aosp_arm, aosp_arm64, aosp_sailfish
and the x86+arm target in mater. Only one libc.so is installed
under recovery/root/system/lib (or lib64).
Change-Id: I83a248d81f2c71dcfb0e9d887a75b71338f27b4d
VisitDepsDepthFirst is almost never correct, as it can't query
dependency tags of multiple dependencies between the same two modules.
Replace VisitDepsDepthFirst with WalkDeps in sanitize.go and
python.go. Also verify the dependency tag before continuing to
recurse to ensure that they don't recurse through genrules and into
unrelated modules.
Test: m checkbuild
Change-Id: I2f7560126f56b51a40ec39dfbdcc18b5891489f7
To save space in the recovery partition, modules installed to the
partition are restricted to be built in the first architecure (i.e.,
32bit for 32bit-only device or when TARGET_PREFER_32_BIT is true, and
64bit otherwise).
Most notably, this change removes the 32-bit variant of the linker
(about 1MB). The linker was installed regardless of whether there is a
32-bit executable or not. Now, the unnecessary linker is not installed
and it is guaranteed that all modules in the partition are built with the
same architecture.
Bug: 79146551
Test: m -j
Test: out/target/product/<name>/recovery/root/system/bin/ has only one
variant of the linker.
Change-Id: I4070a43555bad4cfa8eff5253b09dcd004ea8251
VNDK-Ext are modules with `vndk.enabled: true` but not having
`vendor_available: true`. In addition, VNDK-Ext should be checked by
source ABI checker. This change fixes the regression introduced in
Bug: 110142940
Test: Create libminijail_ext, break some ABIs, and see an error.
Change-Id: I8b47ac12d2e132f641129c9549ed22c3971d6c89
SourceDepTag is going to become a set of tags of the same type
instead of a single tag, remove references to it outside the
android module.
Bug: 80144045
Test: soong tests
Change-Id: I00b2ea5040e4fc95dfbfdd79e21579853c478fcb
When pack_relocations is false and clang lld is used,
pass --pack-dyn-relocs=none to lld.
Bug: 80093890
Test: build and boot with USE_CLANG_LLD=true
Change-Id: I0ffe77a111d7fbab5afaa1395d09734a8a390e09
recovery_available property is required in cc_genrule. Specifically,
we will mark libminijail as recovery_available:true as part of building
adbd and other stuffs for recovery. Some source code of libminijail is
created via cc_genrule, so we need recovery_available in the module
type.
Bug: 79146551
Test: m -j
Change-Id: I0cf0d9b1004dda055373573e5c5a7debd112685f
`recovery: true` installs a module to the recovery partition.
`recovery_available: true` makes a module to be available to other
`recovery:true` or `recovery_available: true` modules.
These to are very similar to vendor, vendor_available properties, except
for the target partition.
Bug: 67916654
Bug: 64960723
Test: m -j, toybox_recovery is installed to the recovery/root/sbin
Change-Id: Iaebe0593de16c69fa70de251a61f4d018a251509
And fix up androidmk / bpfix to provide warnings about what to do
instead.
Test: m blueprint_tools (runs the tests, ensures there aren't any tags left)
Change-Id: I1a3ad8600211050420041740207d6957f44463c8
Previously abi diffs were allowed only on unsanitized variants of vndk
libraries. This CL allows them on all sanitized variants which go onto
production devices, eg: cfi variants.
Bug: 66301104
Test: Without this change, for arm64 libstagefright_foundation doesn't
get an lsdump file since we don't build an unsanitized variant
(aosp_arm64_ab).
Test: With this change, for arm64 libstagefright_foundation does
get an lsdump file (aosp_arm64_ab)
Change-Id: I94f82fd84fc898e4980c3f3619df9677ed723c32
This commit adds `runtime_libs` to cc_binary and cc_library.
Similar to the `required` property, if a module specifies the
`runtime_libs` properties and it is installed, then the modules
specified in `runtime_libs` will be installed as well.
Differnt from the `required` property, if a module is using VNDK and the
module names specified in `runtime_libs` are resolved to the modules
with both core and vendor variants, then '.vendor' will be appended to
those module names.
For example, if `libb` is vendor_available and `libd` is a vendor lib,
then LOCAL_REQUIRED_MODULES will contain `libb.vendor` (instead of
`libb`).
Bug: 72343507
Test: lunch aosp_arm64_ab-userdebug && make # this runs the unit tests
Test: Create a vendor module with runtime_libs property to a
vendor_available shared library and check the generated Android.mk.
Change-Id: I9e245d80004dab597a5d3db5acd8a09117118db7
Bug: http://b/77792074
- Add the libclang_rt.profile runtime libraries directly to the compile
command (for both host and target) instead of relying on the Clang
driver.
- Move the coverage mutator to PreDepsMutators so the mutation has
already happened when runtime libraries are added during dependence
computation.
- Factor out cc/config/toolchain to identify libclang_rt.profile modules
for the x86 and x86_64 host.
Test: make NATIVE_COVERAGE=true produces coverage-enabled host binaries.
Change-Id: I1ebc8cffdf11622bfc18199a57674672888b3a5f
double_loadable is a property that tells whether a module is capable or
being loaded with other instance (possibly an older version) of the same
module in the same process. Currently, a shared library that is a member
of VNDK can be double loaded in a vendor process if the library is also
a dependency of an LLNDK library. Such libraries now must be explicitly
marked as `double_loadable: true` by the owner, or the dependency from
the LLNDK lib should be cut if the lib is not designed to be double
loaded.
Bug: 77155589
Test: m -j
Merged-In: I3b839f860cbdc01f43b59872cd7bb84ac4a7d73e
Change-Id: I3b839f860cbdc01f43b59872cd7bb84ac4a7d73e
(cherry picked from commit 89943d8be2)
Bug: 78118272
Bug: 72225642
Test: SKIP_ABI_CHECKS=true mm -j64 in external/libjpeg-turbo; no abi
dumping / diffing happens
Test: SKIP_ABI_CHECKS=false mm -j64 in external/libjpeg-turbo; abi
dumping / diffing happens
Test: SKIP_ABI_CHECKS=foo mm -j64 in external/libjpeg-turbo; abi
dumping / diffing happens
Change-Id: I6330bc6de81abd589e78572af8efdf70d4c69b80
During link-type check, if a module with sdk_version "current" refers
another, compatibility check between STLs has not been performed.
Bug: 77834464
Test: m -j succeeded
Change-Id: Id82a39372670daca779d4fb4af2deb202170a2fd
This extends the minimal runtime dependency mutator to allow signed
and unsigned integer overflow diagnostics in static libraries and
binaries. This also enables the integer_overflow flag for static
libraries and binaries.
Note compilation will fail if the static library is a dependency
of a Make module that does not also have diagnostics enabled.
Bug: 66952339
Bug: 73283972
Test: make SANITIZE_TARGET{,_DIAG}=integer_overflow
Test: Enabled diagnostics in a static lib, saw results in logcat.
Test: Checked showcommands output for ubsan runtime library inclusion.
Change-Id: Ic52881a0f74cdcac0e4a15335df493b59b002ae5
Normally, when building with VNDK, platform modules are not allowed to
link against vendor libraries, because the ABI of the vendor libraries
are not guaranteed to be stable and may differ across multiple vendor
images.
However, the vendor public libraries are the exceptions. Vendor public
libraries are vendor libraries that are exposed to 3rd party apps and
listed in /vendor/etc/public.libraries.txt. Since they are intended to
be exposed to public, their ABI stability is guaranteed (by definition,
though it is up to the vendor to actually guarantee it).
This change provides a way to make a vendor lib as public by defining a
module of type 'vendor_public_library' with a map file that enumerates
public symbols that are publicized:
cc_library {
name: "libvendor",
proprietary: true,
...
}
vendor_public_library {
name: "libvendor",
symbol_file: "libvendor.map.txt",
}
This defines a stub library module named libvendor.vendorpublic from the
map file. `shared_libs: ["libvendor"]` is redirected to the stub library
when it is from the outside of the vendor partition.
Bug: 74275385
Test: m -j
Test: cc_test.go passes
Change-Id: I5bed94d7c4282b777632ab2f0fb63c203ee313ba
* The extra STL libs are:
libc++abi.a [needed for ndk_libc++_static]
libandroid_support.a [always needed in NDK r16]
libunwind.a [needed for ARM32]
* The existing STL-dependency logic in linkShared only applies to shared
libraries. By moving it to STL deps, the extra STL libs are linked into
both shared libraries and executables.
* Remove the ndk_prebuilt_library/ndkPrebuiltLibraryFactory module type,
which is unused now.
* Reuse the ndk_prebuilt_static_stl module type to describe the extra
static libraries that are linked with both the static and shared libc++
STLs.
Bug: b/73133405
Test: manual
Change-Id: I3f73e4f882d39e6efa470073bb4fc8c42dff8253
We omit vendor unavailable modules. This should not apply to llndk
libraries since currently, we do abi checks on their system variants.
Bug: 77101345
Test: m -j libc creates libc.so.lsdump
Test: m -j libjpeg.vendor creates libjpeg.so.lsdump
Test: m -j external/cblas still does not create libblas.so.lsdump
Change-Id: I5522c1cd471bfba8a1f632270ab2f167b4b17117
The space prevents "repo upload" from running on my machine:
$ repo upload .
[COMMIT 50e35bea87f0] Use Soong modules for the NDK's extra STL libraries
[FAILED] gofmt
FILES: ('cc/cc.go',) <standard input>
[FAILED] repohooks for platform/build/soong failed
FATAL: Preupload failed due to above error(s).
For more info, please see:
https://android.googlesource.com/platform/tools/repohooks/
Bug: none
Test: repo upload
Change-Id: I6b5de8f5d4edb38ca26a999e561df10262844b3d
When building vendor modules with BOARD_VNDK_VERSION=current, the
API of the vendor modules will be current PLATFORM_VNDK_VERSION.
__ANDROID_API_FUTURE__ will be used as before if the version is a
CODENAME.
If BOARD_VNDK_VERSION is not "current", that means the VNDK version
of the vendor modules is BOARD_VNDK_VERSION.
Bug: 74833244
Test: Build and check boot.
Change-Id: I383c76a36101e39c70575b463880b52d3e9d90bb
Test: Add proto.canonical_path_from_root: true in a cc_defaults
Test: Add proto.canonical_path_from_root: true in a java_defaults
Change-Id: I9ddfc8af0025705a34b6e487225f1f98915054c3
Adds Soong support for -fsanitze-minimal-runtime when using
the integer overflow sanitizers. This makes the crashes due to these
sanitizers less mysterious.
Bug: 64091660
Test: Compiled and checked the generated compiler commands
Test: Checked program that overflows for the abort reason
Change-Id: Ieeceaf6c35c8371592952d3b8b977aefc11601c5
Vendor binaries cannot directly link with vndk libraries which are not vendor
available. We don't need them to be abi stable.
Bug: 66301104
Test: cd external/cblas; touch src/cblas_cher.c; mm -j64 does not
produce an lsdump for libblas, since it isn't vendor available,
even though it is vndk_enabled: true.
Change-Id: Ib2e1eaa06c4dc2e05623bd7b9aa3a83010f76bd1
asan variants can sometimes have extra exported symbols (this is a vndk
extension violation). Since asan variants are only used for testing,
don't do abi diffs for them.
Bug: 66301104
Test: Without the change, libc++.so.lsdump exists for the asan variant;
with the change, it does not.
Test: make -j64.
Change-Id: I61a4c7a3e9aa0028a54ad0ca8715e8c77aebad94
Historically, we've always passed '-I .' as the first argument to
protoc, essentially treating all proto file package names as their full
path in the android source tree. This would make sense in a monorepo
world, but it makes less sense when we're pulling in external projects
with established package names.
So keep the same default (for now), but allow individual builds to opt
into using local paths as the default names with
'canonical_path_from_root: false'. A cleanup effort and/or large scale
change in the future could change the default to false.
As part of this, run protoc once per input proto file, since the flags
may need to change per-file. We'll also need this in order to specify
--dependency_out in the future.
Bug: 70704330
Test: aosp/master build-aosp_arm.ninja is identical
Test: aosp/master soong/build.ninja has expected changes
Test: m
Test: Build protobuf test
Change-Id: I9d6de9fd630326bbcced1c62a4a7e9546429b0ce
While the rule may really need all of the generated header files to
exist, only one of them (per genrule task) needs to be in the dependency
list, since the rest are essentially aliases.
This brings an AOSP aosp_arm-userdebug out/soong/build.ninja file from
372MB to 156MB, with equivalent functionality. The Android-aosp_arm.mk
file is reduced from 11MB to 6.5MB.
Bug: 73745773
Test: diff out/soong/build.ninja
Test: diff out/soong/Android-aosp_arm.mk
Test: rm -rf out; m
Change-Id: If17377666292cc20957417fc4c3cd52f98971d0c
Such optimisations may significantly increase the binary size when
compiler heuristics are off. Disabling these helps cut down the
binary sizes with negligible decrease in performance, but allows us to
be more comfortable enabling LTO across various projects.
Test: m
Test: dex2oat, hwui, skia benchmark
Bug: 62839002
Change-Id: Id63e8dd295df2972f76ae4e29ee367080fff8429
LLVM-AR does not allow passing --plugin options more than once. The
--plugin ARFLAGS that lto want to add, may already exist if sanitizer is
also turned on.
Fixed this by adding a new bool Flags.ArGoldPlugin. Set this variable to
true whenever LLVM gold plugin is needed for ArFlags. In function
TransformObjToStaticLib(), add this option to arFlags using global value
${config.LLVMGoldPlugin} if the bool value is true.
Bug: http://b/73160350
Test: build the image with make and succeeded.
Change-Id: I62785829b0a4b663225926e4aed98defc1b6da2c
(cherry picked from commit 4917049f6e)
For the VNDK prebuilt modules that does not match the target arch,
skip installing the module instead of marking the module to prevent
installing.
Bug: 72310137
Bug: 71787263
Test: Install VNDK snapshot v27
lunch aosp_arm64_ab-userdebug; m vndk_v27_arm64
- vndk libs must be installed
m vndk_v27_arm
- no vndk libs must be installed because target does not match
OUT_DIR=out_clean m --skip-make
Change-Id: I9df25d90c276ce5e0d94ec7f9bee32f9ce7231df
This commit adds `extends: "name"` property and provides basic support
to VNDK extensions. This is the simplest example:
```
cc_library {
name: "libvndk",
vendor_available: true,
vndk {
enabled: true,
},
}
cc_library {
name: "libvndk_ext",
vendor: true,
vndk: {
enabled: true,
extends: "libvndk",
},
}
```
A vndk extension library must extend an existing vndk library which has
`vendor_available: true`. These two libraries must have the same
`support_system_process` property.
VNDK-ext libraries are installed to `/vendor/lib[64]/vndk` and
VNDK-SP-ext libraries are installed to `/vendor/lib[64]/vndk-sp` by
default.
If there is a matching abi-dumps in `prebuilts/abi-dumps`,
`header-abi-diff` will be invoked to check for ABI breakages.
Bug: 38340960
Test: lunch aosp_walleye-userdebug && make -j8 # runs unit tests
Test: lunch aosp_arm-userdebug && make -j8 # build a target w/o VNDK
Test: Create a lsdump for a vndk lib, add an exported API to vndk lib,
and build fails as expected.
Test: Create a lsdump for a vndk lib, create an vndk extension lib with
extra API, and build succeeds as expected.
Test: Create libutils_ext, add an extra function to libutils_ext, and
call it from a HIDL service.
Change-Id: Iba90e08848ee99814405457f047321e6b52b2df0
If the target_arch for the snapshot module does not match with
the build variable TARGET_ARCH, hide the module from the make file.
Bug: 71787263
Test: Install VNDK snapshot v27
lunch aosp_arm64_ab-userdebug; m vndk_v27_arm64
- vndk libs must be installed
m vndk_v27_arm
- no vndk libs must be installed because target does not match
Change-Id: I32ab5004832a4164e1b2c056ad149ede50828b92
This build function is unnecessary now that GCC is completely
unsupported for Android platform builds. It is similar to
USE_CLANG_PLATFORM_BUILD from the build/make side of things.
Bug: http://b/64032869
Test: Builds
Change-Id: Iddf5f91cc997c337c77a644265cb8dc4e5a915b4
Added three properties (soc_specific, device_specific, and
product_specific) that shows what a module is specific to.
`soc_specific: true` means that the module is specific to an SoC
(System-On-a-Chip) and thus need to be installed to vendor partition.
This has the same meaning as the old `vendor: true` setting.
`device_specific: true` means that the module is specific to the entire
hardware configuration of a device includeing the SoC and off-chip
peripherals. These modules are installed to odm partition (or /vendor/odm
when odm partition does not exist).
`product_specific: true` means that the module is specific to the
software configuration of a product such as country, network operator,
etc. These modules are installed to oem partition (or /system/oem when
oem partition does not exist). These modules are assumed to be agnostic
to hardware, so this property can't be true when either soc_specific or
device_specific is set to true.
Bug: 68187740
Test: Build. path_tests amended.
Change-Id: I44ff055d87d53b0d2676758c506060de54cbffa0
A llndk_headers module was double defined; one as a header lib and the
other as a static lib. Since llndk_headers is a header lib, the static
lib is now deleted.
Bug: 70617292
Test: build. (TestLlndkHeaders added)
Change-Id: I1a3e9d1a73616ea4faf03664a7a4b03bd5955629
Logtags files in cc and java are treated fundamentally differently.
In cc, they are not used for compiling at all, but need to be passed
to Make to be combined into the global logtags list, and logtag files
are listed in a logtags property. In java they are listed in srcs
and produce generated code that is compiled in, and so shouldn't
also need to be listed in a logtags property.
Move the logtags property to cc and export it to Make from there,
and have java extract logtags files from srcs to be exported to
Make.
Test: m checkbuild
Change-Id: I31d49289efe72db60d2f33566df771b4a3ebc8a0
When BOARD_VNDK_VERSION := <VNDK version>, or
PRODUCT_EXTRA_VNDK_VERSIONS includes the needed <VNDK version> list,
the prebuilt VNDK libs in prebuilts/vndk/ directory will be
installed.
Each prebuilt VNDK module uses "vndk_prebuilt_shared" for shared
VNDK/VNDK-SP libs.
Following is the sample configuration of a vndk snapshot module:
vndk_prebuilt_shared {
name: "libfoo",
version: "27",
vendor_available: true,
vndk: {
enabled: true,
},
arch: {
arm64: {
srcs: ["arm/lib64/libfoo.so"],
},
arm: {
srcs: ["arm/lib/libfoo.so"],
},
},
}
The Android.bp for the snapshot modules will be auto-generated by a
script.
Bug: 38304393
Bug: 65377115
Bug: 68123344
Test: set BOARD_VNDK_VERSION := 27
copy a snapshot for v27
build with make command
Change-Id: Ib93107530dbabb4a24583f4d6e4f0c513c9adfec
AConfig() now duplicates Config(). Replace the uses of AConfig()
with Config(). Leave AConfig() for now until code in other
projects is cleaned up.
Test: m checkbuild
Change-Id: Ic88be643049d21dba45dbd1a65588ed94bf43bdc
Compute sources including from filegroup and genrule dependencies
before determining if any sources will cause flags to be added.
Test: gen_test.go
Change-Id: I0434b003bbda07a58bb2ce1a0a72997918c8fae2
there's no use case for prepending/appending to bool, and string
properties within module struct. Declearing "*bool" and "*string" almost
cover everything user need.
I did see one case that user specify relative_install_path as
path prefix in cc_defaults, and concatenate with the one in real module
to get the final relative install path in Android.bp <bionic/tests/libs>.
Test: m -j checkbuild
Bug: b/68853585
Change-Id: If3a7a2689c3fc307aae136af6bc9c57f27a1e1a0
no_default_compiler_flags is only used by the crt* modules,
is unnecessary, and causes problems when necessary flags like
-no-canonical-prefixes are not passed. Remove the property.
Use useVndk() instead of noDefaultCompilerFlags() to determine
if adding libc as a dependency is necessary and won't cause a
circular dependency.
Bug: 68719465
Test: m checkbuild
Change-Id: Iea1a082dc701dfeab211049a22f7066257347b80
This reverts commit 33c252c2f1.
I have a fix to the crashes that this CL set was causing, and have
uploaded it as a patchset to this revert.
This also contains a partial fix that was initially submitted
separately as
https://android-review.googlesource.com/#/c/platform/build/soong/+/524295/
Bug: 30227045
Test: ./art/test/testrunner/run_build_test_target.py -j110 art-asan #no
build errors
Test: m -j50 ASAN_OPTIONS=detect_leaks=0 SANITIZE_HOST=address # no
build errors
Change-Id: I3e53549fa03413d35d9a952f04de1e7629e1f06d
This reverts commit d4b484b070.
Rationale: second in group of commits that left aosp_x86_64 not
building. (See https://android-build.googleplex.com/builds/
submitted/4426589/aosp_x86_64-eng/latest/logs/build_error.log)
Bug: 30227045
Test: builds
Change-Id: I38ab5284c614d6ee68e7359219bd75c7d50131be
This CL makes multiples changes in preparation for platform-wide CFI.
(a) Adds a second -version-script=... to the command line
when building components that use a version script. This ensures that
__cfi_check is also exported, and allows CFI to be enabled for these
components.
(b) Adds both topdown and bottom up mutators for CFI to help propagate
dependencies correctly for components that may need CFI disabled.
(c) Fixes an issue with the mutators to correctly apply settings to
both generated variants
(d) Fixes issues when components have more than a single visibility
flag.
Bug: 30227045
Test: SANITIZE_TARGET=cfi m -j40 # dependencies are correctly built
# with/without CFI
Change-Id: I44793cc03bcbcdaa957cc49c7240b87d7c9db327
Added export_llndk_headers properties to llndk_library module. And a new
module type llndk_headers is added. This is to enable an LLNDK library
to reexport other LLNDK headers.
Bug: 65395259
Test: do the following
// frameworks/native/libs/arect/Android.bp
llndk_headers {
name: "libarect_vendor_headers",
export_include_dirs: ["include"],
}
// frameworks/native/libs/nativewindow/Android.bp
llndk_library {
name: "libnativewindow",
....
export_llndk_headers: ["libarect_vendor_headers"],
}
check that
-Iframeworks/native/libs/arect/include is in LOCAL_EXPORT_CFLAGS of
libnativewindow.vendor in out/soong/Android-<product>.mk
Change-Id: If1650414b2967f2042f4ebe2b593ed3f3ea45d3a
Also adds checks that the dependencies are android.Modules and
are not disabled.
Test: m checkbuild
Change-Id: I05e945f38915d49cd3c0ab72a86576949bc7eff2
Move firstUniqueElements to android.FirstUniqueStrings,
lastUniqueElements to android.LastUniqueStrings, and lastUniquePaths
to android.LastUniquePaths.
Test: m checkbuild
Change-Id: Ieac840405126c7f8f98afb4a4ef35c01a18fe7fb
This uses knowledge of transitive dependencies to reorder
linker command line arguments such that if module A depends
on module B, then module A is automatically listed before
module B in the linker command line.
This should mostly remove the need for Android.bp files to
list all of their static dependencies in link order
Bug: 66260943
Test: reorder the entries of static_libs in an Android.bp and see that linking still succeeds
Change-Id: I20f851ab9f2f30031254e4f30023b6140d15d6c3
linkageMutator removes srcs property of the shared variant of a lib in
order to reuse *.o files compiled for the static variant also to the
shared variant.
However, this causes problem when vendor-specific srcs are specified in
target: {vendor: {srcs: ["..."]}}. For example, let's assume
cc_library {
name: "libfoo",
srcs: ["foo.c"],
target: {
vendor: {
srcs: ["bar.c"],
},
},
}
Then,
static_vendor: inputs = foo.o, bar.o
shared_vendor: inputs = foo.o (from static_vendor), bar.o (from
static_vendor), bar.o
So, bar.o is included twice and this causes multiple symbol definition
error.
In order to handle the problem, vendor mutator is applied before the
linkage mutator and the vendor-specific srcs are squashed in the vendor
mutator.
Bug: 67731122
Test: build
Test: cc_test.go
Change-Id: I2a5390295dddfc41260e9b6f02746908cdf47228
When a lib is explicitly marked as `vendor_available: false`, then it
can't be directly depended by a vendor lib which is installed to /vendor
partition. This is to hide some VNDK libs (including llndk) from vendors
so that platform owners can have a freedom of modifying their ABI
without breaking vendors.
In addition, the list of the private libs are exported to the make world
as VNDK_PRIVATE_LIBRARIES.
Also, fixed a bug that allowed a vndk lib to link against to vendor
library (or vendor variant of a system lib) if the lib is prebuilt.
Bug: 64730695
Bug: 64994918
Test: Add `vendor_available: false` to libft2 and libcompiler_rt.
Add the libs to shared_libs property of a vendor library in soong
(i.e. libnbaio_mono). The build fails with the error message.
Change-Id: Iab575db96bb4f6739a592f3fa0a75124296bea0c
Bug: http://b/65598278
The profile runtime depends on libgcc for some symbols (only under some
circumstances - armv5, ndk r14, static executables). Since Android
build passes -nostdlib and adds libgcc manually, the profile runtime
gets passed to the linker later than libgcc.
Instead, explicitly add the profile runtime to the linker command (and
pass one other flag added by the clang driver to the link).
Test: Build a library with profile instrumentation that otherwise fails
instrumented build.
Change-Id: I24b34cebd2c3bb6a540f8f4c465ace1be4eb90f3
Signed-off-by: Pirama Arumuga Nainar <pirama@google.com>
This reverts commit 2370af0e23.
Reason for revert: New Build Breakage: aosp-master/aosp_arm64_ab-userdebug @ 4376965
Change-Id: Ibe4b819c4292457c454bf42e6d94fba3071ec04b
Bug: http://b/63768402
Bug: http://b/65598278
Add support for the 'pgo' property to specify how a module is processed
under PGO. A sample property is below:
pgo: {
instrumentation: true, // could be "sampling: true" when supported
profile_file: "pgo_simple.profdata",
benchmarks: ["pgo_simple"],
}
1. Runtime profiles can be gathered using "sampling" or
"instrumentation". Sampling is not supported initially.
2. If 'toolchain/pgo-profiles' project is found,
'toolchain/pgo-profiles/${profile_file}' is passed to the compiler and
linker when building this module.
3. If ANDROID_PGO_INSTRUMENT environment variable is set, and includes a
benchmark in the 'benchmarks' list, appropriate flags (for e.g.
-fprofile-generate for instrumentation) are passed to the compiler and
linker when building this module.
Test: Add example modules that specify the pgo property and verify
appropriate flags and dependencies in the Ninja file. Some
tests/examples are in https://android-review.googlesource.com/474805
Change-Id: I6242e0c904497a115e367dea6927ba1c4b906355
The linux kernel requires that the ELF interpreter (runtime linker)
that's referenced by PT_INTERP be either an absolute path, or a relative
path from the current working directory. We'd prefer a relative path
from the binary, similarly to how we handle looking up shared libraries,
but that's not supported.
Instead, extract the load sections from the runtime linker ELF binary
and embed them into each host bionic binary, omitting the PT_INTERP
declaration. The kernel will treat it as a static binary, and we'll use
a special entry point (linker_wrapper) to fix up the arguments passed by
the kernel before jumping to the embedded linker. From the linker's
point of view, it looks like the kernel loaded the linker like normal.
Bug: 31559095
Test: Enable host bionic,
out/soong/host/linux_bionic-x86/nativetest64/libdemangle_test/libdemangle_test
Change-Id: I8d0aea9790b5e86fcc3ea6e2d00cfa33907e2853
cc_genrule is the same as a normal genrule, but can depend on other cc
modules (like cc_object).
Test: mmma external/minijail
Change-Id: I8df87665c7bdc76ce89c92755c054f967a818e57
So that we don't get confused when using :<module> in srcs to depend on
a module that could also be a HostBinTool.
Test: m -j
Change-Id: Ia3b1c26826e70f84c6dc5ff78c95dd11d76901b6
Currently, abi is dumped for platform variants of system libraries.
Dump them for vendor variants since they are the ones which need to be abi
stable on security updates. This also ties abi dumping to BOARD_VNDK_VERSION.
Test: For libfoo:
1) Added a source file with a dummy function for the core
variant.
2) Excluded the source file from the vendor variant.
3) BOARD_VNDK_VERSION=current mm -j64 produces libfoo.so.lsdump with no
dummy_function since the source file was not included in the vendor
variant.
Test: Inspected build.ninja and confirmed that all of a library's abi
dump dependencies (.sdump files are dependencies of the final .lsdump files) are
from vendor variants.
Change-Id: Ie0bf91fcd81606c131845d9872261166b5db72aa
launcher.
For Python2, we bundle embedded launcher as bootstrapper within every
.par file. This feature is only enabled for linux_x86_64 for now. We
provide a user flag: hermetic_enabled within bp file. By default, Pyhon2
still use classic bootstrapping way to construct .par file and relys on
host interpreter. Once embedded_launcher is enabled, launcher will be
used to bootstrap .par file and execute user program.
For Python3, the launcher will be ready soon, and for now it still relys
on classic bootstrapping.
Test: Real example is used to test.
Bug: b/63018041
Change-Id: I28deba413d8ad3af407595e46f77d663e79a3705
All the stats below are for a hikey960-eng build on AOSP master.
Number of order-only inputs in out/soong/build.ninja:
Before: 2847162
After: 606508
Size of: Before After
out/soong/build.ninja 572MB 233MB -59%
out/soong/Android-hikey960.mk 15MB 9MB -40%
out/build-hikey960.ninja 367MB 358MB -2%
Ninja time in `m nothing`:
Before: 6.9s
After: 5.0s
Soong generation time:
Before: 11.6s
After: 6.6s
Test: m nothing
Test: wrote script that counted inputs, only duplicates were removed
Test: treehugger
Change-Id: I6b7c5ef5b1395014b7bf5fd0b8112d42bee127bf
header-abi-diff has switched to recursive diffing of types and can
diff more accurately if types included in re-exported shared library
headers are included as well.
Bug: 62060883
Test: make -j64, android.hardware.light@2.0.so.lsdump contains structs
from libcutils as well (libcutils' headers are re-exported by
android.hardware.light@2.0)
Change-Id: I814819e4f7258b4b380350fe8ad0ccf8dbd5ce5c
Right now this is hard coded in two places (here and in
core/binary.mk). Keep it in one place so it's easier to change.
Test: make checkbuild
Bug: None
Change-Id: I2a2c784d4c667b326f871e6144db92753c16c85f
Enabling the lto property for a module builds that module and all static
dependencies with LTO.
LTO (link-time optimization) allows the compiler to optimize and
generate code for the entire module at link time, rather than
per-compilation unit. LTO is required for Clang CFI and other
whole-program optimization techniques. LTO also allows cross-compilation
unit optimizations that should result in faster and smaller code, at the
expense of additional compilation time.
Test: make -j12 libc with lto: true for libc
Change-Id: Ib8baefedf60e02701d44673a7c473e0845730101
LL-NDK, VNDK-core, VNDK-SP libraries are exported to make as
SOONG_LLNDK_LIBRARIES, SOONG_VNDK_CORE_LIBRARIES, and
SOONG_VNDK_SAMEPROCESS_LIBRARIES. This can be used to auto-generate
ld.config.txt from a template.
Bug: 64013660
Test: BOARD_VNDK_VERSION=current m -j successful
Test: check out/soong/make_vars*.mk and look for SOONG_*_LIBRARIES
Merged-In: I0f4c5d05d9cd28c3fc9fdcca6ce0e6eaeaacbe8d
Change-Id: I0f4c5d05d9cd28c3fc9fdcca6ce0e6eaeaacbe8d
When the lib is vendor-only, then .vendor suffix is not added.
Furthermore, this change correctly adds .vendor suffix even to the names
listed in LOCAL_SHARED_LIBRARIES so that we don't need to add the suffix
in the make world.
This also allows us to use the original name (without the .vendor
suffix) of the vendor-only modules in make (e.g. in PRODUCT_PACKAGES or
as a make target).
Bug: 37480243
Test: BOARD_VNDK_VERSION=current m -j <name> is successful, where <name>
is one of the vendor-only libraries in Soong. (i.e.
android.hardware.renderscript@1.0-impl)
Test: m -j does not break anything
Change-Id: I203e546ff941878a40c5e7cfbb9f70b617df272d
'vndk' tag must be parsed in cc_defaults as well.
Test: build with a module that has 'vndk' tag in cc_defaults.
Change-Id: I21a5a831dbf8cae00be98c00f4bb98504da53c8d
InitDefaultsModule and InitDefaultableModule were requiring the
module to be passed in as an argument twice, once as a
android.Module and once as an android.DefaultableMOdule. Use
a type assertion instead.
Test: builds
Change-Id: I57d721e68a4f016e02c17a678af5f2ba25a9a430
If BOARD_VNDK_VERSION is set, and a module is set to
`vendor_available: true` it is installed in /system and /vendor.
However, if the module is a VNDK library, it must be
installed at `/system/${LIB}/vndk` instead of /vendor/${LIB}.
For those modules, need following to set.
vendor_available: true,
vndk: {
enabled: true,
support_system_process: true,
},
`support_system_process` is optional to define.
If it is defined to true, the module is regarded as vndk-sp.
link-type check for VNDK modules is added to make sure that VNDK
modules only link to other VNDK shared libraries or LL-NDKs.
move the ABI checks to VNDK from all of vendor_available.
Bug: 38304436
Test: attempt to compile with BOARD_VNDK_VERSION:=current
Test: Use `vendor_available_vndk: true` for VNDK modules and compile
with BOARD_VNDK_VERSION:=current
Change-Id: I409268e0b7f05a9d01697bf9f9f4726b5aac631f
If a vendor (or vendor_available) lib has a dependency to a llndk
library, the name of the llndk library is modified to <name>.llndk.
There was a bug that this name modification is done only for shared_libs
property, but not for export_shared_lib_headers property. As a result,
the headers of the llndk was not re-exported. Fix the bug by modifying
export_shared_lib_headers property as well.
Bug: 63178444
Test: build
Test: look into out/soong/Android-<target>.mk. libutils.vendor has
system/core/liblog/include_vndk in its LOCAL_EXPORT_CFLAGS.
Change-Id: I6fcb1036cdb81ba167ead815b436a5cada283ede
Change module factories from returning a blueprint.Module and a list
of property structs to returning an android.Module, which holds the
list of property structs.
Test: build.ninja identical except for Factory: comment lines
Change-Id: Ica1d823f009db812c518f271a386fbff39c9766f
Add a list of flags which are not understood by clang LibTooling tools
and filter them out of the Cflags the tools are invoked with.
Test: In frameworks/av, make libmedia vendor_available (this invokes
header-abi-dumper on this module), mm -j64.
Bug: 62447349
Change-Id: I46f017212b89f4331145c999103d0ed44da0abaf
We now add export_static_lib_headers, export_generated_headers to the
filters while dumping the abi of a library using header-abi-dumper
(through -I<dir> additions to the invocation of header-abi-dumper and
header-abi-linker)
Also add support for zipped reference source based abi dumps.
Test: mm -j64 in hardware/interfaces/nfc/default/1.0 produces
android.hardware.nfc@1.0.so.lsdump with abi filtered out using generated
headers.
Test: Copied the linked abi dumps produced by mm -j64 in bionic/libc to
prebuilts/abi-dumps/ndk and gzipped them. Ran mm -j64 again in
bionic/libc and verified header-abi-diff getting invoked.
Bug: 32750600
Change-Id: I26210af908c87a6143e39fa25f50307acb68a387
Soong command lines have gotten very long due to hidl modules
reexporting lots of libraries. Dedup the include dir flags.
Test: m -j checkbuild
Change-Id: I6ada1251012da42344e2c00ae66001a649023d2c
The deps have to be exported alongside the headers to make sure
the headers are in place when a module that depends on the shared
library builds.
Bug: 37555583
Test: use protos in a cc_library
Change-Id: I8f5b8d7937868458c1cf02b990a348aa395634da
hasSrcExt is used to determine extra flags and dependencies when
generated files are used. If the generated files are being handled
in a static library whose objects are reused in a shared library,
the flags and dependencies still need to apply. Instead of clearing
the source files in the shared library, move them to an OriginalSrcs
property, and check that in hasSrcExt along with the Srcs property.
Also pass extra exported include directories from the static
library to the shared library.
Bug: 37555583
Test: use protos in a cc_library
Change-Id: I709779ec03b66b220b7bd58a1f6f0b9b5067d955
header-abi-dumper: dumps abi exported by source files for Vndk.
header-abi-linker: links abi dumps produced by header-abi-dumper.
header-abi-diff: compares linked dumps.
Test: mm -j64 showcommands > make_log in bionic/libc.
This produced linked dumps in out/soong/.intermediates.
Copied these dumps to
prebuilts/abi-dumps/ndk/current/arm64/source-based/.
Changed the abi and re-ran mm -j64 showcommands > make_log
confirmed that the build reported compatibility breakge without
actually failing (advisory mode).
Change-Id: Iccad6908fe68a80f47230751671d156893b96ead
Nothing changes if BOARD_VNDK_VERSION isn't set.
When the VNDK is enabled (BOARD_VNDK_VERSION in Make), this will split
/system and /vendor modules into two different variant spaces that can't
link to each other. There are a few interfaces between the two variant
spaces:
The `llndk_library` stubs will be available in the /vendor variant, but
won't be installed, so at runtime the /system variant will be used.
Setting `vendor_available: true` will split a module into both variants.
The /system (or "core") variant will compile just like today. The
/vendor ("vendor") variant will compile against everything else in the
vendor space (so LL-NDK instead of libc/liblog/etc). There will be two
copies of these libraries installed onto the final device.
Since the available runtime interfaces for vendor modules may be
reduced, and your dependencies may not expose their private interfaces,
we allow the vendor variants to reduce their compilation set, and export
a different set of headers:
cc_library {
name: "libfoo",
srcs: ["common.cpp", "private_impl.cpp"],
export_include_dirs: ["include"],
target: {
vendor: {
export_include_dirs: ["include_vndk"],
exclude_srcs: ["private_impl.cpp"],
srcs: ["vendor_only.cpp"],
},
},
}
So the "core" variant would compile with both "common.cpp" and
"private_impl.cpp", and export "include".
The "vendor" variant would compile "common.cpp" and "vendor_only.cpp",
and export "include_vndk".
Bug: 36426473
Bug: 36079834
Test: out/soong/build.ninja, out/soong/Android- only changes due to _core addition and
.llndk -> .vendor
Test: attempt to compile with BOARD_VNDK_VERSION:=current
Change-Id: Idef28764043bf6c33dc0d2e7e2026c38867ff769
Soong can rename these automatically for internal use, so don't require
users to set these.
Bug: 33241851
Test: Android-aosp_arm.mk is the same before/after
Test: build.ninja is the same before/after
Test: build-aosp_arm.ninja is the same before/after
Merged-In: Ia92356a0ec079f908fd49812231228046783e50d
Change-Id: Ia92356a0ec079f908fd49812231228046783e50d
The vendor image will have more than just proprietary modules in it
under Treble, so let's stop marking open source code as proprietary just
to move it to vendor.
Bug: 36452052
Bug: 37134596
Test: compare build.ninja before/after, no changes.
Test: Set vendor: true, ensure it works.
Change-Id: I44b0ec7007d0e311bdcbd44b238b1ef2d05cc6ff
Instead of using the NDK headers and libraries, add LL-NDK specific
headers and library stubs for VNDK users. This allows us to provide an
expanded liblog interface.
Test: aosp_arm; m -j
Test: Enable BOARD_VNDK_VERSION on aosp_arm; m -j
Test: Inspect out/soong/build.ninja before/after (w/o vndk)
Change-Id: Ic85f07fa10c695b5baab10c41f5e0ad38700bf3d
This CL moves the location of ASAN-ified libraries on disk in the
following manner:
/data/lib* --> /data/asan/system/lib*
/data/vendor/* --> /data/asan/vendor/*
There are a couple of advantages to this, including better isolation
from other components, and more transparent linker renaming and
SELinux policies.
Bug: 36574794
Bug: 36674745
Test: m -j40 && SANITIZE_TARGET="address" m -j40 and the device
boots. All sanitized libraries are correctly located in /data/asan/*.
Change-Id: I06bf459260ec451d4495a02562f640ad622f34c2
Include order should be module includes, dependency exported includes,
and then global includes. Module includes and global includes are
computed during compileFlags, but dependency exported includes are
not handled until later. Move the global includes into a new
flags variable so that the dependency includes can be appended
to the module includes.
Test: m -j native
Change-Id: Ifc3894f0a898a070d6da8eed4f4b9e8cc0cd2523
Instead of having a module define `use_vndk: true`, assume that we're
building with the VNDK if we're installed on the vendor partition, and
BOARD_VNDK_VERSION==current. This now matches our behavior in Make.
Once BOARD_VNDK_VERSION!=current, we'll need to disable modules that
need to otherwise compile against the VNDK, since we can only compile
against the current VNDK.
Test: build.ninja for aosp_arm is the same before/after
Test: Ensure there are no boards that set BOARD_VNDK_VERSION
Change-Id: If937fa7bdb119648137af52daebadf486163484b
This was corrupting the nonvariants list with the variants list whenever
it hit the else case, causing a missing variant issue, since we need to
use the variant when linking against lib*.ndk.
Test: aosp_arm build.ninja is the same before/after
Test: https://android-review.googlesource.com/c/355163/, set
BOARD_VNDK_VERSION := current
Change-Id: I047937e838464670d0902506871d2203ec8cc17d
This reverts commit 4c48f724e1. It's
causing test failures, warnings and complaints, so backing it out and
we'll resolve those before putting it back in.
Bug: 33681361
Test: m -j
Adds the ability to set custom flags for ar in Soong, similar to how
they can currently be set for make.
Bug: 36290748
Test: sanitize.go is able to correct set custom ar flags for CFI. CFI
enabled Soong components build and boot without issue.
Change-Id: I3212793aa84ba51df910c184d8bb376b3650376e
Shared libraries are now installed to different directories depending on
their types.
* NDK libraries: /system/lib/ndk
* VNDK libraries: /system/lib/vndk
* VNDK-ext libraries: /system/lib/vndk-ext
* Framework-only libraries: /system/lib
* Vendor-only libraries: /vendor/lib
* Same-process HALs: /vendor/lib/sameprocess
In addition, a new module type vndk_ext_library is added. It is almost
identical to cc_shared_library but it introduces another attribute
'extends'. This is use to reference the vndk library that this vndk-ext
library is extending.
For example, in order to extend a vndk library libFoo:
cc_library {
name: "libFoo",
srcs: [...]
}
---------------------
vndk_ext_library {
name: "libFoo-extended",
srcs: [...]
extends: "libFoo"
}
Then, libFoo will be installed as /system/lib/vndk/libFoo.so and
libFoo-extended will be installed as /system/lib/vndk-ext/libFoo.so.
Note that file name of the latter is libFoo.so, not libFoo-extended.so:
file name of an extending module is automatically set to that of the
extended module.
Bug: 33681361
Test: build & run. Libraries must be in the correct directories.
Change-Id: Ia1eb3940605d582a252c78da0f3a5b36fdab062b
This is configured the same as make -- a global NATIVE_COVERAGE=true
flag to allow native coverage, then COVERAGE_PATHS=path1,path2,... to
turn it on for certain paths.
There are .gcnodir files exported to Make and saved in $OUT/coverage/...
files which are `ar` archives containing all of the compiler-produced
.gcno files for a particular executable / shared library.
Unlike the Make implementation, this only passes links the helper
library (automatically through --coverage) when one of the object files
or static libraries being used actually has coverage enabled.
Host support is currently disabled, since we set -nodefaultlibs, which
prevents libclang_rt.profile-*.a from being picked up automatically.
Bug: 32749731
Test: NATIVE_COVERAGE=true COVERAGE_PATHS=system/core/libcutils m -j libbacktrace libutils tombstoned
$OUT/coverage/system/lib*/libcutils.gcnodir looks correct (self)
$OUT/coverage/system/lib*/libbacktrace.gcnodir looks correct (static)
$OUT/coverage/system/lib*/libutils.gcnodir doesn't exist (shared)
$OUT/coverage/system/bin/tombstoned.gcnodir looks correct (executable)
Test: NATIVE_COVERAGE=true COVERAGE_PATHS=external/libcxxabi m -j libc++
Confirm that $OUT/coverage/system/lib*/libc++.gcnodir looks correct (whole_static_libs)
Change-Id: I48aaa0ba8d76e50e9c2d1151421c0c6dc8ed79a9
filegroup is a module that contains a list of files, and can be used
to export files across package boundaries. filegroups (and genrules)
can be referenced from srcs properties of other modules using the
syntax ":module".
Test: m -j
Change-Id: I3d6fc4819c0b4225b474e0ad42f0d947f55a5961
Pass a DepsContext that embeds android.BottomUpMutatorContext
instead of android.BaseContext so that dependency methods can
directly add dependencies.
Test: m -j
Change-Id: Id4c157975d3d6f03efd99785d217bef486a76139
To date we have been using static libraries with no source files as
header-only libraries. Switch to using header_libs to make the user's
expectations clear, in case we need to differentiate the semantics of
static libraries and header-only libraries when we enable transitive
static library dependencies.
Test: mma -j external/llvm
Change-Id: I3ce16df11076b637bd192880e86ec9027738b9e7
Push the "depens on a disabled module" dependency to runtime when
SOONG_ALLOW_MISSING_DEPENDENCIES is set so that subsets of the tree
can build when some modules are disabled.
Test: external/clang/build.py on llvm branch
Change-Id: I47e4f41d04aa3df173757f03a0c581b0bafb93f0
Ideally we'd calculate the headers that are written here too, but I'll
add that in a later change that actually enforces the generated header
list.
Test: mmma -j system/tools/aidl
Change-Id: Ifd2e8e8ff444b0f67270fb5156e7bf7bceddb6be
LLVM has complicated static library layering that sometimes changes.
The make solution was to list all the static libraries twice, but
Soong dedups the list. Add a group_static_libs flag to allow
surrounding the static libs with -Wl,--start-group and
-Wl,--end-group.
Test: mmma -j external/llvm
Change-Id: Ic08a183d7def9c9249d4a3014760759f16b68d04
