This is needed for a follow up change that makes sure that the
prebuilt modules have the same visibility as the source modules.
Bug: 143678475
Test: m conscrypt-module-sdk
Change-Id: I9461c8c094ab19ee9ececb5e5fd50565789f2fa2
For VNDK snapshot and SDK snapshot, deps files have been used to capture
generated headers. But exported deps might contain intermediate phony
files instead of actual header files, which are for optimization of
ninja. To correctly capture all headers, exported generated header files
are gathered separately.
Bug: 65377115
Test: m nothing
Change-Id: Ia03fa69186490a818578190e3c0bfb0261d1fd6e
Extracts the type specific functionality into the SdkMemberType
interface which has to be implemented by each module type that can
be added as a member of the sdk. It provides functionality to add
the required dependencies for the module type, check to see if a
resolved module is the correct instance and build the snapshot.
The latter was previously part of SdkAware but was moved because
it has to be able to process multiple SdkAware variants so delegating
it to a single instance did not make sense.
The custom code for handling each member type specific property,
e.g. java_libs, has been replaced with common code that processes
a list of sdkMemberListProperty struct which associates the
property (name and getter) with the SdkMemberType and a special
DependencyTag which is passed to the SdkMemberType when it has to add
dependencies.
The DependencyTag contains a reference to the appropriate
sdkMemberListProperty which allows the resolved dependencies to be
grouped by type.
Previously, the dependency collection methods would ignore a module if
it was an unsupported type because they did not have a way of
determining which property it was initially listed in. That meant it
was possible to add say a droidstubs module to the java_libs property
(and because they had the same variants) it would work as if it was
added to the stubs_sources property. Or alternatively, a module of an
unsupported type could be added to any property and it would just be
ignored.
However, the DependencyTag provides information about which property
a resolved module was referenced in and so it can detect when the
resolved module is of the wrong type and report an error. That check
identified a bug in one of the tests where the sdk referenced a
java_import module (which is not allowed in an sdk) instead of a
java_library module (which is allowed). That test was fixed as part
of this.
A list of sdkMemberListProperty structs defines the member properties
supported by the sdk and are processed in order to ensure consistent
behaviour.
The resolved dependencies are grouped by type and each group is then
processed in defined order. Within each type dependencies are grouped
by name and encapsulated behind an SdkMember interface which includes
the name and the list of variants.
The Droidstubs and java.Library types can only support one variant and
will fail if given more.
The processing for the native_shared_libs property has been moved into
the cc/library.go file so the sdk package code should now have no type
specific information in it apart from what is if the list of
sdkMemberListProperty structs.
Bug: 143678475
Test: m conscrypt-module-sdk
Change-Id: I10203594d33dbf53441f655aff124f9ab3538d87
This commit enables ABI checks for shared libs exported by APEX and
explicitly enabled ABI checks.
Bug: 145608479
Test: m com.android.resolv
Change-Id: I3b58178b0258df35fcc848e84642152516f6774f
cc.LinkableInterfaces should be able to request if an empty variant is
required from the LinkageMutator. We were previously assuming that if only
static or shared libraries were being built, then we didn't need the
empty variant. However this should be explicit to handle cases where the
default set of variants being created may not include both static and
shared libraries.
Bug: 144861059
Test: m -j crosvm.experimental
Change-Id: I66724bdc16ff350b06dfa4d049c82f33019979a5
Prepare for making the image mutator available to all modules and
moving it between the os and arch mutators by moving it into the
android package and using an interface implemented by the module
types to control it.
Bug: 142286466
Test: No unexpected changes to out/soong/build.ninja
Change-Id: I0dcc9c7b5ec80edffade340c367f6ae4da34151b
Native compiler flags are currently applied in approximately:
global cflags
local cflags
local include dirs
global include dirs
global conlyflags
local conlyflags
global cppflags
local cppflags
This means that a flag that is enabled in the global cppflags
cannot be disabled in the local cflags, and an Android.bp author
must know to disable it in the local cppflags.
The previous CL split the global and local flags into separate
variables. Rearrange the order that the variables are applied
to be:
global cflags
global conlyflags
global cppflags
local cflags
local include dirs
local conlyflags
local cppflags
global include dirs
Bug: 143713277
Test: m native
Change-Id: I171524ab40096a636a8e549e1e4bc3347ef9f97a
Native compiler flags are currently applied in approximately:
global cflags
local cflags
local include dirs
global include dirs
global conlyflags
local conlyflags
global cppflags
local cppflags
This means that a flag that is enabled in the global cppflags
cannot be disabled in the local cflags, and an Android.bp author
must know to disable it in the local cppflags. A better order
would be:
global cflags
global conlyflags
global cppflags
local cflags
local conlyflags
local cppflags
local include dirs
global include dirs
We are mixing both the global and local cflags into a single
variable, and similar for conlyflags and cppflags, which
prevents reordering them. This CL prepares to reorder them
by splitting the global and local cflags into separate variables.
Bug: 143713277
Test: m native
Change-Id: Ic55a8c3516c331dc5f2af9d00e59ceca9d3e6c15
This is a follow-up CL of I9a24f6975bd4b226a94f61a13d43857dcdce6b88
Generated files are passed to make via MakeVars:
- SOONG_LLNDK_LIBRARIES_FILE
- SOONG_VNDKCORE_LIBRARIES_FILE
- SOONG_VNDKSP_LIBRARIES_FILE
- SOONG_VNDKPRIVATE_LIBRARIES_FILE
- SOONG_VNDKCOREVARIANT_LIBRARIES_FILE
- SOONG_VNDK_LIBRARIES_FILE
Previously filenames were "guessed" from module names. Now VndkMutator
stores filenames as well and generate those files with them.
Bug: 142963962
Bug: 141450808
Test: m && device boots && TH
Change-Id: I0c248b707188f904df60ead50059fefe90bfd17f
Adds the ability for rust modules to be compiled as C libraries, and
allows cc modules to depend on these rust-generated modules. This also
means that soong-rust should not have any dependencies on soong-cc aside
from what's required for testing.
There's a couple small fixes included as well:
- A bug in libNameFromFilePath that caused issues when library's had
"lib" in their name.
- VariantName is removed from rust library MutatedProperties since this
was unused.
Bug: 140726209
Test: Soong tests pass.
Test: Example cc_binary can include a rust shared library as a dep.
Test: m crosvm.experimental
Change-Id: Ia7deed1345d2423001089014cc65ce7934123da4
The snapshot script can now handle native shared libs in an SDK.
Bug: 138182343
Test: create following sdk module:
sdk {
name: "mysdk",
native_shared_libs: ["libc", "libdl"],
}
, then execute `m mysdk` and execute the update_prebuilt-1.sh as
prompted. Following directories are generated under the directory where
mysdk is defined at:
1
├── aidl
├── Android.bp
├── arm64
│ ├── include
│ ├── include_gen
│ └── lib
│ ├── libc.so
│ └── libdl.so
├── include
│ └── bionic
│ └── libc
│ └── include
│ ├── alloca.h
│ ├── android
│ │ ├── api-level.h
<omitted>
Change-Id: Ia1dcc5564c1cd17c6ccf441d06d5995af55db9ee
Adds an interface, CcLinkableInterface, for cc linkable dependencies
which come from other toolchains such as Rust.
Bug: 140726209
Test: Soong tests pass, rust modules still compile.
Change-Id: I7378a46fad94fd0b735746aaf4e265fd2c2c04d8
exportedDirs and exportedSystemDirs are now changed to android.Paths so
that we can later manipulate the paths via Rel(), etc.
Test: m
Change-Id: I6fb02ea4983bcebac351bc284f75b44885379e8f
vndk-ext should have the same output filename with the lib which it
extends. "extends" property is "module name", not "filename" of output.
Bug: 143130384
Test: add "protox" as a vndk-ext module (extends 'libprotobuf-cpp-full')
m protox.vendor && check output filename under /vendor/lib/vndk/
(should have correct suffix)
Change-Id: I5741ea87b4f2ad375b69f54c93dcb8753d9952dd
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
Create a new type InstallPath that is similar to OutputPath to
differentiate intermediates output paths from installed output
paths.
RelPathString is a poorly defined, undocumented function that is
primarily used to get an install path relative to out/soong to
generate an equivalent install path for Make relative to $(OUT_DIR).
Move it to InstallPath for now, and fix the one remaining user on
OutputPath.
Add a method to create an NDK install path so that ndk_sysroot.go
doesn't have to do it manually with PathForOutput.
Bug: 141877526
Test: m checkbuild
Change-Id: I83c5a0bd1fd6c3dba8d3b6d20d039f64f353ddd5
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
Translated second architectures now go in NativeBridgeArch instead
of DeviceSecondaryArch.
This reapplies I568046330abc002d4eed582cb999b62a5eaba790 with
ctx.Config().HasMulitlibConflict() added to fix the NDK build,
which has arm64, arm, x86_64, and x86 architectures enabled.
Test: m checkbuild
Test: OUT_DIR=out_ndk build/soong/scripts/build-ndk-prebuilts.sh
Test: no change to build.ninja or Android-aosp_cf_x86_phone.mk
Change-Id: Iadcafbd64bfb9579ae7c86914927c43a062b0c8e
This reverts commit fe6330c7d2.
Reason for revert: this was accidentally propping up NDK builds
Bug: 141242600
Change-Id: Ie9f8e31479a74e8e9e14d720a5936da6b1d5d113
Translated second architectures now go in NativeBridgeArch instead
of DeviceSecondaryArch.
Bug: 141242600
Test: m checkbuild
Change-Id: I568046330abc002d4eed582cb999b62a5eaba790
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
And make prebuilt shared libraries suffix and stem too.
This will be used for the vendor version of the protobuf
runtime shared libraries to append the protobuf version
number to the installed file name, which will help with
updating protobuf in the future.
Bug: 117607748
Test: m checkbuild
Change-Id: I8919a4f2e1be1ced29198af758077baf56c1f7a7
Merged-In: I8919a4f2e1be1ced29198af758077baf56c1f7a7
Move handling the inject_bssl_hash property to a helper function,
and also treat it as set if any static libraries have it set.
Bug: 137267623
Test: m checkbuild
Change-Id: Icb12cfffb20797c807b410daffbf7fcccb1b1975
The header ABI checker is enabled by default for the libs that are used
across APEXes.
Bug: 138219814
Test: m
Change-Id: Ic0e9c5fdfa1259f500d990abc504c452436f3bd7
sysprop_library now checks the API stability itself, cutting dependency
on java_sdk_library. Under the directory {module_dir}/api,
{module_name}-current.txt and {module_name}-latest.txt hold API
signatures.
When sysprop_library is built, or a user run "m {module_name}-check-api"
command, API check is performed. First, current.txt must have exactly
same signature with built sysprop_library module. Second, current.txt
must be compatible with latest.txt.
Build system emits a handy error message to generate/update those API
files, in case of missing or mismatching. Also, a script file for
freezing API files is introduced.
Bug: 131637873
Test: 1) m && boot blueline
Test: 2) m {sysprop_library} performs API check
Test: 3) manual test for check-api, freezing api
Change-Id: I9d25f5dc64299e666527ca8e23d7233966901c4e
Merged-In: I9d25f5dc64299e666527ca8e23d7233966901c4e
Merged-In: Ib7ad4f17e82c90da5ef3f80e2ab88c0b53112c60
(cherry picked from commit 093f0eb133)
* 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.
external/boringssl needs to run a tool on a shared library, but
cc_genrules currently don't support shared libraries as inputs
or outputs. Use a property to trigger the desired behavior for
now.
Bug: 137267623
Test: m libcrypto
Change-Id: I75b4a761f8a4f2c65a99453d2781d6d0f93106ef
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
For all vndk snapshot libraries, header files exported by the libraries
will be included to the snapshot. Android.bp will contain necessary
information to link against/install vndk snapshot libraires:
export_include_dirs, export_system_include_dirs, export_flags, and
relative_install_path.
Bug: 132818174
Test: 1) m nothing && mv out/soong/build.ninja /tmp && m nothing &&
diff -u -u out/soong/build.ninja /tmp/build.ninja
Test: 2) VNDK_SNAPSHOT_BUILD_ARTIFACTS=true \
development/vndk/snapshot/build.sh
Test: 3) development/vndk/snasphot/update.py
Test: 4) see contents of Android.bp and include directories
Change-Id: I791ab181545eb483242b04446afd40958bbb2b17
This commit adds tags, such as NDK, VNDK-core, and PLATFORM, to
LSDUMP_PATHS. The script updating the reference ABI dumps uses the tags
to determine the directories where the dumps should be created.
Test: make findlsdumps
Bug: 133176785
Change-Id: I8540286238cf0ec55c65e1c4f60cb9c12e5e57a1
If sort_bss_symbols_by_size is true, a shared library is built twice.
The first build generates an unsorted output file, which is used to
generate the symbol ordering file. The output of the second build is
a shared library with its bss symbols sorted by their size.
With this, the only user of symbol_ordering_file, libc, is migrated to
use the new property, so we remove symbol_ordering_file support as well.
Bug: 135754984
Test: Build and check the resulting libc.so has its bss symbols sorted.
Change-Id: I5c892b44d82eb99cbc070cfa2c680be3087f3364
Export LLNDK_MOVED_TO_APEX_LIBRARIES which is used by make
to filter out LLNDK libs that been migrated to an APEX.
It's used by the ld.config.txt generaton, and to filter out
the vndk_package dependencies.
Test: Build&flashed crosshatch image
Bug: 137320025
Change-Id: I1449dad79edf36a628fa1ac15c35f163dbd8ee2a
Bug: 137015854
Test: m
Test: build cf_x86_phone and ensure there is no dangling symlink
/system/lib/arm/libm.so
Change-Id: I0f5efdb9e1f5e4e213ca4ebaa28ace0a130b36a6
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
In the first design, public sysprops have been accessible from Java
modules linking against SDK. But SDK modules shouldn't do, because
sysprop_library isn't for the apps. This renames system to public, so
that only public(System till now) and internal scopes remain from now.
Bug: 131637873
Test: m && sysprop_test
Change-Id: I548007d4a6018922f98d3d13915cee1d66070086
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
This reverts commit 6d8c0a50bc.
The switchover to lld appears to be making adb crash on exit for unclear
reasons. Revert it as a quick fix pending further investigation.
Bug: http://b/134613180
Test: adb.exe under windbg
Change-Id: Ibdf5981c3c6828b3684974b7c30a7c96449c64c5
I'm not sure if these sections are used, but by adding them to
libgcc_stripped.a, we can end up with multiple .gnu_debuglink sections in
an executable, where the first two unhelpfully point at "libgcc.a". e.g.:
$ readelf -SW -x.gnu_debuglink out/target/product/walleye/system/bin/bootstrap/linker64
...
Section Headers:
...
[18] .gnu_debuglink PROGBITS 0000000000000000 10f19c 000020 00 0 0 1
...
[22] .gnu_debuglink PROGBITS 0000000000000000 18a2c8 000010 00 0 0 4
...
Hex dump of section '.gnu_debuglink':
0x00000000 6c696267 63632e61 00000000 3d5f65d8 libgcc.a....=_e.
0x00000010 6c696267 63632e61 00000000 3d5f65d8 libgcc.a....=_e.
Hex dump of section '.gnu_debuglink':
0x00000000 6c696e6b 65723634 00000000 f85db7ea linker64.....]..
Bug: none
Test: m libgcc_stripped linker
Test: no .gnu_debuglink section in libgcc_stripped.a
Test: only one .gnu_debuglink section in system/bin/bootstrap/linker64
Change-Id: I0c47a9acd6d52f5cbc5bfa8b67d072ebb075a242
This was removed in
https://android-review.googlesource.com/c/platform/build/soong/+/950885
because it appeared that bionic was always in an APEX, but apparently the
ART host tests have bionic outside of an APEX.
Test: art/test/testrunner/run_build_test_target.py -j50 art-linux-bionic-x64
Change-Id: I0b99462e8636da53c87f9250093689aaaf9ea695
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
Allow a cc_prebuilt_library_shared to share the same name as a
cc_library by always creating static and shared variants of
prebuilts so that the variants of the source module are always
a superset of the variants of the target module.
Bug: 131709055
Test: TestPrebuilts
Change-Id: I4afd6d37e6a986d08ad25aee69eca6d994febc6b
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
