Revert submission 1242911-sdk_version_variant
Reason for revert: b/153394225
Reverted Changes:
Ife99745fb:Use libnativewindow for platform variant of libagq...
I1bae84c43:Use libnativewindow for platform variant of androi...
I6e6021ed3:Use stl to depend on libc++
Ife99745fb:Use libnativewindow for platform variant of libRSS...
I2c9f439b9:Fix static dependency on libprotobuf-cpp-lite-ndk
Iff2aff9cf:Set sdk_version for cc_genrules used by modules wi...
I7d72934aa:Add sdk mutator for native modules
Ief378a007:Use sdk variant of Soong modules when LOCAL_SDK_VE...
Bug: 149591340
Change-Id: I798fa902c779469c6382b6699351e5d12bf14785
Fixes: 153394225
Compiling native modules against the NDK disables platform features
like ASAN. For anything shipped on the system image there is no
reason to compile against the NDK. Add a new mutator to Soong that
creates a platform and an SDK variant for modules that set
sdk_version, and ignore sdk_version for the platform variant. The
SDK variant will be used for embedding in APKs that may be installed
on older platforms. Apexes use their own variants that enforce
backwards compatibility.
Test: sdk_test.go
Test: TestJNIPackaging
Bug: 149591340
Change-Id: I7d72934aaee2e1326cc0ba5f29f51f14feec4521
Necessary to get correct prebuilts for many Bionic libs.
Cleaned up numerious "system_shared_libs: []" from test fixtures, since
they otherwise would need correction in the expected results, and it is
better to have a single test focused on testing system_shared_libs
propagation.
Test: m nothing
Bug: 152255951
Change-Id: If2e8a5296223e6281d833312660e8e9e4cd184c0
This change ensures that the runtime dependencies between a
binary/shared library are correctly specified in the snapshot so that
the build can ensure that shared libraries are built before the targets
that use them.
It adds support for differentiating between references that are
required to refer to another sdk member (required) and those that may
refer to either an sdk member or a non-sdk member (optional). The
latter is used for shared library references as the libraries used by
an sdk member may be provided from outside the sdk. e.g. liblog is not
part of the ART module but is used by some members of the ART sdk.
Bug: 142935992
Test: m nothing
Change-Id: Ia8509ffe79b208c23beba1880fe9c8a92b732685
Remote execution and other tools can be confused by references to
build_number.txt without a dependency. Add an order-only dependency,
which maintains the current behavior.
Test: BUILD_NUMBER=1 && m aapt && aapt version # shows 1
BUILD_NUMBER=2 && m aapt && aapt version # shows 1
rm out/soong/.intermediates/frameworks/base/tools/aapt/aapt/linux_glibc_x86_64/aapt
BUILD_NUMBER=2 && m aapt && aapt version # shows 2
Change-Id: Icfa98d6840b1dc2e273ba29c33011635d1cf93b1
This is to support enabling scudo only for non-svelte configs.
Also, add exclude_static_libs to allow removing the jemalloc libs.
Bug: 137795072
Test: Verified that a svelte and non-svelte config can use this method
Test: to properly choose between scudo and jemalloc.
Change-Id: Iec6bfe159f8491138e93dde1d225a8c874c7ce31
Instead of linking the unwinder statically into every binary, link it
dynamically, by exporting the symbols from libc.so. This has a number
of advantages:
- Reduces image size (system.img size decreases by 1.7MB on walleye-userdebug,
and 1.2MB on crosshatch-userdebug).
- Allows us to easily change/upgrade the unwinder throughout the system,
including vendor prebuilts.
- Allows code outside of libc++ to define custom personality routines.
Previously, personality routines would call the unwinder routines in the
local binary, which would cause problems with unwinders with global state
(such as the libgcc unwinder) if the copy of the unwinder used for unwinding
(normally libc++'s copy) were different from the copy linked against the
personality routine.
Bug: 144430859
Change-Id: I3b2a4a3ee58c6777989f811e19a3aeb47c0945bd
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
libclang_rt.builtins has default visiblity set to public and is the
last included static library for all modules. This means that it is
possible for libraries to pick up libclang_rt.builtins from their
shared library dependencies, instead of libclang_rt.builtins directly.
Particularly, a vendor prebuilt in AOSP was picking up __floatditf()
from libhidlbase.so instead of from libclang_rt.builtins. A change to
libhidlbase.so that removed the symbol caused thos prebuilt to fail to
link at runtime.
Bug: 138809247
Test: build, boot internal
Test: don't see libclang_rt.builtins symbols in libhidlbase.so
Merged-In: I0348c4860fe02cf88cb89f7ab356bd8c17826d77
Change-Id: I0348c4860fe02cf88cb89f7ab356bd8c17826d77
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
Change ctx.Config().BuildNumberFromFile() to be unescaped, and then
escape it manually where necessary. This will allow passing
ctx.Config().BuildNumberFromFile() to RuleBuilder, which will handle
the necessary escaping.
Test: no change to out/soong/build.ninja
Change-Id: I5329ab2ba70ccea49958864488aa81794a7e4b56
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
no_libgcc is no longer needed anywhere. Move all occurances to no_libcrt
and remove no_libgcc.
Test: build
Change-Id: I6dd49db71d05d7685aa90cc837627f65e6742d6d
We use libgcc as fallback for symbols not present in libclang_rt
builtins, however we didn't know what exact symbols were being used,
some may not be intended to fallback.
Create libgcc_stripped, which only contains unwind symbols from libgcc.
Bug: 29275768
Test: bionic-unit-tests
Change-Id: I5b349fa6138e51663bf3b67109b880b4356da8e8
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
In addition, add Shared_libs to malloc_not_svelte.
Bug: 123689570
Test: Verified that libc_scudo is first wherever it is added.
Change-Id: Ibdc5dbd019a382630a727c270f846aa4446f8d99
Merged-In: Ibdc5dbd019a382630a727c270f846aa4446f8d99
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
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
Follow the change to blueprint to make *Escape take and return a string
and add *EscapeList that take and return slices of strings. Fix up
a few places that were unnecessarily converting a string to a slice
and back to a string.
Test: m nothing
Change-Id: I3fa87de175522205f36544ef76aa2f04aef1b936
libcrt is crashing libc on x86/x86_64 for unknown reason. This enables
us to disable libcrt for these architectures for libc for now.
Test: m checkbuild
Bug: 29275768
Change-Id: I5a717286b3d9cc1ba8cdcd33bafb9c225de4aff8
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 removes a special case that ignores `system_shared_libs`
when `sdk_version`, `vendor_available`, or `vendor` is specified.
In the past, that special case was required for `libasync_safe` and
`libpropertyinfoparser`. However, ignoring `system_shared_libs` meant
that we didn't have a way to skip the default libs when `sdk_version`
was specified. This becomes a problem when the dependencies of
prebuilts are actually checked. To be specific,
`libclang_rt.builtins-${arch}` falls into circular dependencies.
Bug: 123006819
Test: make checkbuild
Change-Id: I5fe038c00892b3abe5189b30d57ba59884b47cbb
We add an optional Symbol_ordering_file property to linker properties
to allow modules to specify the order of symbols in the binary.
Bug: 112073665
Test: Build libc with a symbol ordering file and check the resulting
binary.
Change-Id: Ibb24697cfdee4a5750442cb74f1ee6390d8a6430
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
This patch fixes an issue that SHR_RELR relocation is not supported by
SDK version earlier than API 28. We only turn it on when SDK is not
used, or SDK version is newer than or equal to API 28.
Test: m -j48 for aosp_taimen-userdebug
Bug: http://b/119086751
Change-Id: I33124ae4f35fb8c00ae9103e8c04e2d4ccd5fec3
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
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
This should always be true now. It will be a change for side branches
(build_tools, etc) that weren't setting UseClangLld in the
soong.variables file.
Test: treehugger
Change-Id: I9fd6157fda630bf8bb939677dbcb026f02685f19
