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
This reverts commit 61166dc047.
One difference from the earlier change is that import libraries are now
using the '.lib' extension instead of '.a' to prevent clash with
AdbWinApi.a.
Bug: http://b/110800681
The following flags that the binutils linkers support are not
available in lld for Windows:
-soname
--no-undefined
-rpath
Windows also uses "import libraries", which are stub libraries used only
for linking. The binutils linkers accepted a DLL and treated them as an
import library. But lld issues the following error:
lld-link: error: ...DLL: bad file type. Did you specify a DLL instead
of an import library?
To resolve this, pass '-out-implib=libFoo.lib' to lld when linking
libFoo.dll to get lld to generate an import library. Add libFoo.lib as
an implicit output to the 'ld' build rule.
Rewrite the shared libraries when building a library/binary to use the
import library instead of the DLL. As a side-effect, this also uses the
newly-created AdbWinApi.lib that's alongside
development/host/windows/prebuilt/usb/AdbWinApi.dll
Test: Run Windows tests (go/android-llvm-windows-testing) and check
absence of regressions. Also check that the following commands pass:
$ adb.exe devices
$ fastboot.exe devices
Change-Id: I34e07d345e0207086ac8e8ea12525d8c322b20fd
This commit add `--llndk` to the command line option for
`create_reference_dumps.py` as well.
Bug: 124620774
Bug: 130324828
Test: lunch aosp_arm64-userdebug && make
Change-Id: I117864209b8cf8c934fd3aa1086b7691c1c449e3
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_library_static
* cc_library_shared
* cc_library
* cc_library_host_static
* cc_library_host_shared
* cc_library_headers
Bug: b/128337482
Test: Generated the documentation and verified that the synopsis was
added to each of the module.
Change-Id: I4d9bb622dc75aad9ea1b9f331c80ed56ddbc9a15
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
Bug: http://b/110800681
The following flags that the binutils linkers support are not available
in lld for Windows:
-soname
--no-undefined
-rpath
Windows also uses "import libraries", which are stub libraries used only
for linking. The binutils linkers accepted a DLL and treated them as an
import library. But lld issues the following error:
lld-link: error: ...DLL: bad file type. Did you specify a DLL instead
of an import library?
To resolve this, pass '-out-implib=libFoo.a' to lld when linking
libFoo.dll. Add libFoo.a as an implicit output to the 'ld' build rule.
Rewrite the shared libraries for a library/binary to use the import
library instead of the DLL. As a side-effect, this also (correctly)
uses the AdbWinApi.a that's alongside
development/host/windows/prebuilt/usb/AdbWinApi.dll
Test: Run Windows tests (go/android-llvm-windows-testing) and check
absence of regressions.
Change-Id: I15a178589aa6882caa6e7e38650cc6ef48109764
Move the logic from ctx.ExpandSources into android.PathsForModuleSrc
and ctx.ExpandSource into android.PathForModuleSrc, and deprecate
them. When combined with the pathDepsMutator this will let all
properties that take source paths also take filegroups or genrule
outputs, as long as they are tagged with `android:"path"`.
Test: All soong tests
Change-Id: I01625e76b5da19240e9649bf26a014eeeafcab8f
Host does not need the symlink. It also broke master-art-host targets.
Test: ALLOW_MISSING_DEPENDENCIES=true
DIST_DIR=~/temp
./art/tools/dist_linux_bionic.sh -j50 showcommands
com.android.runtime.host
Change-Id: Ie8e02553c5a1b6cd5afebd73a64268d2950fc18e
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
Add `android:"path"` to all properties that take paths to source
files, and remove the calls to ExtractSource(s)Deps, the
pathsDepsMutator will add the necessary SourceDepTag dependency.
Test: All soong tests
Change-Id: I488ba1a5d680aaa50b04fc38acf693e23c6d4d6d
Because this flag is used internally by sysprop_library.
Bug: N/A
Test: m -j
Test: build cc_library with setting sysprop property and fail
Change-Id: I478889b8923f99407a067e5b9efee9322c3e5ae8
This commands adds `--llndk` to `create_reference_dump.py` command if
the module with incompatible ABI changes is an LLNDK or a NDK lib. This
prevents people from uploading a CL that simply removes ABI dumps (the
result even when the uploader runs the command).
Bug: 124620774
Test: Make an incompatible ABI changes in libaaudio and see the flag.
Change-Id: I9f07f879193bd4d73f5924baff298d28d6fe1506
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
Add an opaque OnceKey type and use it for all calls to Once in
build/soong. A future patch will convert the arguments to
Once* to OnceKey once users outside build/soong have been updated.
Test: onceper_test.go
Change-Id: Ifcb338e6e603e804e507203c9508d30ffb2df966
... except for Darwin Mach-O, as it is not supported by llvm-strip.
Test: m checkbuild
Bug: 119221035
Change-Id: I021637b6dd3530bff1f563f2ec7c2168e1083b7e
Bootstrap bionic (the bionic in the system partition that is for the
early processes before the runtime APEX is ready) is now located under
./bootstrap subdirectory. i.e.,
* /system/lib[64]/bootstrap/lib{c|dl|m}.so
Before this change, the bootstrap bionic were self bind-mounted. This is
causing problem with `adb sync` because the path which is a mount point
couldn't be unlinked and thus rewriting is not done.
Now, the mount points and mount sources are clearly separated.
Bug: 120266448
Test: m libc.bootstrap libm.bootstrap libdl.bootstrap
Following files are found under system and recovery/root/system
./lib[64]/bootstrap/libc.so, libdl.so, libm.so
Change-Id: I90399b3181988814ce07875df8c1a36599f3337f
This commit adds a header_abi_checker section so that the library owner
can have a fine-grained control over the ABIs that must be checked.
For example, a library "libexample" may have following configurations:
cc_library {
name: "libexample",
header_abi_checker: {
symbol_file: "libexample.map.txt",
exclude_symbol_versions: ["LIBEXAMPLE_PRIVATE"],
exclude_symbol_tags: ["platform", "apex"],
},
}
Bug: 122845490
Test: Add header_abi_checker to libc to filter out LIBC_PRIVATE
Change-Id: I60cfea868f815afe6213c242ed0ca818161d55c6
Allow specifying export_static_lib_headers and export_shared_lib_headers
in the static or shared properties of cc_library modules.
Use a named struct for the properties to avoid having to create
a runtime struct type since none of the properties are filtered.
This avoids running into the name length limit in runtime.StructOf.
Fixes: 122882789
Test: m checkbuild
Change-Id: Ib0e9933e93981ba44668a19ed748bd12a4dd4257
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
Stubs libs are built with the generated version script file.
Bug: 120266448 (comment #23)
Test: lunch walleye_hwasan-userdebug
make SANITIZE_TARGET=hwaddress oatdump
Change-Id: I38652e61d0b336227b7f541590b0e70fe291f0a3
This CL fixes the problem that when a lib is defined with stubs, the
stubs variantof the lib is installed to the APEX. This was happening
because the non-stubs variant is the last variant of the 'version'
variants and addFarVariationDependencies selects the first variant when
the 'version' variant isn't specified.
Fixing the problem by making the non-stubs variant (whose name is "")
the first variant.
Test: m (apex_test)
Change-Id: I1505fd2f29a0d70c916bad51000aa06f2b80b137
The dependency is added because the module that uses the sysprop library
needs generated code before it is built.
Test: m -j
Change-Id: I2858fc6fa6f2fe16afa2f4a7ae62746ba0f67e5c
Now, symbols that are only to be visible to across APEXes can be tagged
as # vndk. Then when generating the stubs library, the tagged symbol
is included. The symbol is NOT included in other cases; build NDK stubs,
etc.
Bug: 120638081
Test: m (apex_test updated.)
Change-Id: Idb2b552badddfc26af113cc8d4b984788f478813
Otherwise, the force included headers might cause conflicting types
error with the symbols in the generated stubs source code. e.g.
double acos(double); // in header
void acos() {} // in the generated source code
Bug: 120266448
Test: m (apex_test also updated, and passing)
Change-Id: I717df990959d1b24ec515f0f52a4e28b94e92f32
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
Stubs libs are build-time only artifact. Can't be installed.
Test: OUT_DIR=out build/soong/scripts/build-ndk-prebuilts.sh
with https://android-review.googlesource.com/c/platform/frameworks/av/+/846770/7
and two more CLs in the same chain
Examine out/soong/build.ninja
Build rule for out/soong/target/product/generic_arm64/system/lib64/arm64/libmediandk.so
exist only once.
Change-Id: I58ff09ef3fbbdbd2d968aa21b87a493192d4216d
Stubs libs are not built with dependencies required for cfi and stl.
Also it does not make much sense to build stubs with cfi and stl because
the libs are not for runtime and there is no C++ symbols.
Test: cherry-pick ag/5747464 and m
Change-Id: I83d6d82513a77a6a8a345e7d12707940c2c906c7
Add dependencies for source modules when they are referenced in
library.Shared/Static.Srcs. Use ExpandSources to expand filegroups
for these properties.
Bug: http://b/120534727
Test: make
Change-Id: I58d02d8f7d60026abbcde75298c7a61b27bdbf12
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
Even though we aren't doing any linking for static libraries, the
default libraries (libc, libm, libdl) are now exporting headers, so we
should be using those for both static and shared libraries (especially
when re-using objects between the two). Without this we've been in a
state where a cc_library will compile differently than a
cc_library_shared, as we'd re-use the compilation units from the static
variant in the shared library.
This does require marking many of libc's dependencies as not using libc
with system_shared_libs, otherwise we run into dependency loops.
Test: treehugger
Change-Id: Ie42edc5184f315f998db953594e425214b810e0e
When dist'ing a library or binary that has use_version_lib set, always
distribute the stamped version, even for the device.
Test: m test_build_version_test dist
Change-Id: I2995ec516b1d182ce18f099aeaa4d186ffbcf01f
This allows modules to override exiting libraries
with custom implementations.
Bug: http://b/114470065
Test: make
Change-Id: I2692a5416a2620ab2268df8998dd2620074adc1f
When building against libFoo#ver, __LIBFOO_API__ macro is set to ver so
that headers from libFoo can be conditionally compiled (e.g., hide APIs
that are not available for the version, etc.)
Bug: 112672359
Test: m (cc_test added)
Change-Id: I863ef95b385cdd842eec1bf34e81f44b5e3b58b3
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
From now on, a c++ shared library can be built only with adding
".sysprop" description file to srcs. Sysprop library generator will
automatically generate a .cpp and .h files, and the header file will be
exposed to any clients linking against the shared library. For the full
schema of description file, see system/tools/sysprop/sysprop.proto.
Bug: 80125326
Test: 1) write a .sysprop description file.
2) create cc_library_shared and add description file to srcs.
3) create another module, link against library of 2), include generated
header, and access generated sysprop functions
4) see compile succeeded.
Change-Id: I95005a0724aeb8f11a856b7aee92787a16a5374d
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
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
The relocation packer prebuilt is gone, remove the references to it.
Bug: 110715614
Test: m checkbuild
Change-Id: Ia20f8198e4fc206f4995dd5168c811dac7c9df89
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
This is common to binaries and libraries, so move it from library.link
and binary.link to baseLinker.linkerFlags and baseLinker.linkerDeps.
Test: make checkbuild
Bug: None
Change-Id: I5fb24118e601673ae0713a6adc773a1565749be8
