Becase there can be more than one stub libraries, LOCAL_MODULE should be
suffixed with SubName just like NDK stub.
Note that suffix should not be appended to the latest version if the
library is provided by APEX, Otherwise, those libs always need to be
referenced with suffix in .mk files.
Bug: 145796956
Test: m
Merged-In: If503fa651a63b0b215742553b250ecf5e0a30971
Change-Id: If503fa651a63b0b215742553b250ecf5e0a30971
(cherry picked from commit ad4c18765e)
Exempt-From-Owner-Approval: cherry-pick from aosp
Host binaries by default use the UBSan runtime whether or not
diagnostics are requested in the module definition. The rest of the code
assumes the runtime is only needed when diag properties are set.
This makes sure to add the runtime to the dependency graph of host
binaries that are UBSanitized.
Bug: 150336284
Test: ./art/tools/dist_linux_bionic.sh com.android.art.host
Test: runtime appropriately identified as a dependency of libziparchive
Change-Id: I2704aaba4abc7f4e6d96747917c77b5147fd1d56
Merged-In: I2704aaba4abc7f4e6d96747917c77b5147fd1d56
(cherry picked from commit f3b190f8e7)
Native modules within APEX should be linked with proper stub version
according to its min_sdk_version.
For example, when min_sdk_version is set to "29", libfoo in the apex
would be linked to libbar of version 29 from platform, even if it has
a newer version like 30.
Bug: 145796956
Test: m nothing (soong tests)
Merged-In: I4a0b2002587bc24b7deeb5d59b6eeba5e1db5b1f
Change-Id: I4a0b2002587bc24b7deeb5d59b6eeba5e1db5b1f
(cherry picked from commit 03b5185b88)
Exempt-From-Owner-Approval: got ORV already.
When there is a runtime depedency (via runtime_libs property) to a
library providing stable C APIs, the dependency is considered as
crossing APEX boundary. Therefore, the requested lib doesn't need to be
made available to the APEX where the requesting lib is in.
Exempt-From-Owner-Approval: cherry-pick from aosp, approved there.
Bug: 147813447
Test: m
Merged-In: I9cf8a5877850fb85b92c851e15fac921b8b7641b
(cherry picked from commit 323a4c3ab3)
Change-Id: I9cf8a5877850fb85b92c851e15fac921b8b7641b
Host binaries by default use the UBSan runtime whether or not
diagnostics are requested in the module definition. The rest of the code
assumes the runtime is only needed when diag properties are set.
This makes sure to add the runtime to the dependency graph of host
binaries that are UBSanitized.
Bug: 150336284
Test: ./art/tools/dist_linux_bionic.sh com.android.art.host
Test: runtime appropriately identified as a dependency of libziparchive
Change-Id: I2704aaba4abc7f4e6d96747917c77b5147fd1d56
The sdk snapshot creates two prebuilts for each member one that is
versioned and one that is not. If they are both installed then they
lead to duplicate rules in make for creating the same installed file.
This change adds an installable property to cc modules that will
prevent the installation of the file and then adds installable: false
on the versioned prebuilt for cc modules.
Bug: 142935992
Test: m nothing
Change-Id: I4cb294c2b0c8a3f411eea569775835d9e41726d6
Only disable CFI on incompatible variants rather than the base module.
Bug: 142157676
Test: Manual llvm-cfi-verify checks
Change-Id: I999e1dbcccc1ffb102b2fe01c47f1bda4df5e601
Updates the member snapshot creation code to support multiple os types.
It basically sorts the variants by os type, then applies the code to
optimize the arch properties and then it optimizes the properties that
are common across architectures and extracts any properties that are
common across os types.
The java and cc member types needed to be modified to make the location
of the generated files within the snapshot os type dependent when there
is more than one os type. That was done by adding an OsPrefix() method
to the SdkMemberPropertiesBase which returns the os prefix to use when
there is > 1 os type and otherwise returns an empty string.
Added three tests, one for cc shared libraries, one for cc binary and
one for java header libraries.
Bug: 150451422
Test: m nothing
Change-Id: I08f5fbdd7852b06c9a9a2f1cfdc364338a3d5bac
sdk_version is passed for relevant variants.
If not specified or "current",
it maps to "10000" for platform variants, and
"min_sdk_version" of the apex for apex variants.
Bug: 150860940
Test: m (soong test)
manually check build.ninja
Change-Id: I5102ab0c5086b5ad29d16ac45af55d32062167b4
This was required before MinGW's default crt was set to ucrt. In the
new setting, libmsvcrt.a is similar to libucrt.a and is implicitly
linked-in by the Clang driver. Not explicitly linking in ucrt avoids
the link-order issue discussed in
https://github.com/android/ndk/issues/1198.
Test: m native-host-cross, go/android-llvm-windows-testing.
Change-Id: Idc125e550cae2f0eb812ca310d1d4be898a29ab4
Becase there can be more than one stub libraries, LOCAL_MODULE should be
suffixed with SubName just like NDK stub.
Note that suffix should not be appended to the latest version if the
library is provided by APEX, Otherwise, those libs always need to be
referenced with suffix in .mk files.
Bug: 145796956
Test: m
Change-Id: If503fa651a63b0b215742553b250ecf5e0a30971
Native modules within APEX should be linked with proper stub version
according to its min_sdk_version.
For example, when min_sdk_version is set to "29", libfoo in the apex
would be linked to libbar of version 29 from platform, even if it has
a newer version like 30.
Bug: 145796956
Test: m nothing (soong tests)
Change-Id: I4a0b2002587bc24b7deeb5d59b6eeba5e1db5b1f
cc_fuzz reexports transient dependeny DSO's to /data/fuzz through Make.
We intentionally export the non-stripped variants so that ClusterFuzz
can use the symbolized variant, but we don't re-export to
/symbols/data/fuzz. This means that tools like `stack` and
`hwasan_symbolize` can't pick up the symbols and don't know what to do.
Fix this by re-exporting to /symbols/ as well.
Bug: N/A
Test: make example_fuzzer && ls
$ANDROID_PRODUCT_OUT/symbols/data/fuzz/arm64/lib
Change-Id: Id0343c95a0a83e16e6f67f29ff6361fb4d757c05
Generalize the processing of arch specific properties to reduce
duplication in snapshot module creation and simplify addition of
support for handling multiple os types.
Supporting multiple os types with the current method for building
snapshot modules would require every affected module type to add
support for it. Rather than duplicate multiple os type handling code
across those module types this work generalizes the process cc modules
use for handling arch types as it can be used as a basis for handling
multiple os types. Migrating module types over to this new process
will insulate them from having to handle multiple os types.
OB
SdkMemberType changes:
* BuildSnapshot is deprecated in favour of the new AddPrebuiltModule()
method.
* Additional methods, CreateVariantPropertiesStruct() and
FinalizeModule() are added.
* A new interface SdkMemberProperties, is defined that handles
extracting information from the variant (prior to common value
optimization) and adding properties to a property set.
The sdk module type uses these new methods and types to delegate the
member type specific processing to the relevant member types while
handling the behavior that is common across all members types, e.g.
extracting common values across multiple architectures. A future change
will leverage this processing to add support for multiple os types.
This change also refactors the cc module processing to use the new
process.
Bug: 150451422
Test: m nothing
Change-Id: If6ab2498407b17f50391d062cd9afc01b5e01af4
Use AndroidMkEntries so the next patch can use ExtraFooters, which
doesn't exist in AndroidMkData.
Bug: 149591522
the bug is not exactly related to this change, but it is the bug
that the follow-up changes are trying to fix.
Test: manually diff out/soong/Android.aosp_x86_64.mk
Merged-In: Ia3006b6747813693cf7e2b536030b21f3109f538
Change-Id: Ia3006b6747813693cf7e2b536030b21f3109f538
(cherry picked from commit d80cbca76d)
VNDK and vendor snapshot singleton work in a single thread, so globbing
in singleton results in ridiculus running time. Moving codes to
GenerateAndroidBuildActions to reduce running time.
Bug: 150406226
Test: VNDK_SNAPSHOT_BUILD_ARTIFACTS=true m dist vndk vendor-snapshot
Test: vendorSnapshotSingleton build time became 0.56s (from 10s)
Test: build.ninja building time became 1m11s (from 1m21s)
Change-Id: I4a081eef5847c62ca00280ca426f5b4e10f87b59
Merged-In: I4a081eef5847c62ca00280ca426f5b4e10f87b59
(cherry picked from commit eda2e9c728)
VNDK and vendor snapshot singleton work in a single thread, so globbing
in singleton results in ridiculus running time. Moving codes to
GenerateAndroidBuildActions to reduce running time.
Bug: 150406226
Test: VNDK_SNAPSHOT_BUILD_ARTIFACTS=true m dist vndk vendor-snapshot
Test: vendorSnapshotSingleton build time became 0.56s (from 10s)
Test: build.ninja building time became 1m11s (from 1m21s)
Change-Id: I4a081eef5847c62ca00280ca426f5b4e10f87b59
To build vndk-ext for product variants use `vndk.extends` property
with `product_specific: true` as for the vndk-ext for vendor
variants. For example:
cc_library {
name: "libvndk_ext_product",
product_specific: true,
vndk: {
enabled: true,
extends: "libvndk",
},
}
It will install the vndk-ext libs for product variants in
product/lib[64]/vndk/
Test: m nothing
Bug: 147778025
Change-Id: If1ee5be93c579abad302f44f18e6316f27e70019
Merged-In: If1ee5be93c579abad302f44f18e6316f27e70019
(cherry picked from commit 0ecf0b223f)
To build vndk-ext for product variants use `vndk.extends` property
with `product_specific: true` as for the vndk-ext for vendor
variants. For example:
cc_library {
name: "libvndk_ext_product",
product_specific: true,
vndk: {
enabled: true,
extends: "libvndk",
},
}
It will install the vndk-ext libs for product variants in
product/lib[64]/vndk/
Test: m nothing
Bug: 147778025
Change-Id: If1ee5be93c579abad302f44f18e6316f27e70019
Removing XOM had the side effect of removing "-z separate-code", which
was needed to override a new default after a recent toolchain update.
This led to some performance regressions in some tests. For now, add
this flag to the global arm64 device flags to return to the previous
behavior.
Bug: 150506341
Test: m -j
Change-Id: I26a93deb17868103eaa4b87bd7bb8416f3adbc7f
Merged-In: I54787954141d133e245dfd259a37bf4c3c8e7caa
(cherry picked from commit c80bbb46b1)
Removing XOM had the side effect of removing "-z separate-code", which
was needed to override a new default after a recent toolchain update.
This led to some performance regressions in some tests. For now, add
this flag to the global arm64 device flags to return to the previous
behavior.
Bug: 150506341
Test: m -j
Change-Id: I54787954141d133e245dfd259a37bf4c3c8e7caa
This is rarely used feature but cost alot for the local build and build
inra.
Bug: 150506627
Test: m
Change-Id: Iec3ada4a97c7b228f2818563fa0e81b407f2715a
When there is a runtime depedency (via runtime_libs property) to a
library providing stable C APIs, the dependency is considered as
crossing APEX boundary. Therefore, the requested lib doesn't need to be
made available to the APEX where the requesting lib is in.
Bug: 147813447
Test: m
Change-Id: I9cf8a5877850fb85b92c851e15fac921b8b7641b
