libc++[abi] always check whether one of these macros is defined, not
the value the macro is defined to. With the new libc++, there is a
Windows __config_site header that automatically defines
_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS and _LIBCPP_HAS_THREAD_API_WIN32
to nothing, so these definitions need to match to avoid a redefinition
error.
Bug: 175635923
Test: treehugger
Test: m adb
Change-Id: I1e48947c3b45e59804cdacd48776c7f3bd9a18c6
Remove the ConvertWithBp2build implementations from all the module
types, along with the related code.
Bug: 315353489
Test: m blueprint_tests
Change-Id: I212672286686a318893bc7348ddd5a5ec51e77a7
Soong currently adds -isystem
prebuilts/ndk/current/sources/cxx-stl/system/include to modules that
have ndk_system STL. This does not translate well to Bazel because of
its stricter sandboxing constraints.
In preparation for building sdk variants with Bazel, create an
indirection where sdk variants that use this STL depend on a
`ndk_system` header library module.
This should be a no-op in Soong, but the resultant ninja files are not
identical. (e.g diff https://diff.googleplex.com/#key=OOLtc1GFmDDF). The
-isystem now appears _before_ the local cflags. However, this should be
fine because we have a check in `CheckBadCompilerFlags` that bans use of
-I/-isystem in user-provided cflags.
Test: diff'd ninja file
Test: TH
Bug: 298258442
Change-Id: I8c4e2b66bb9ac25c44ceedd52298ba474a554a04
There is no prebuilt libc++ for riscv64 provided by the NDK, build
it using the platform sources instead.
Test: lunch aosp_riscv64-userdebug && m -k
Change-Id: Ib9c99381e61331e10c136127a3f1b1626ce75ebe
This will obsolete the workaround in prebuilts/ndk/Android.bp to
export the ndk_libandroid_support headers from ndk_libc++_shared,
which would no longer have worked after the next patch.
Test: m checkbuild
Test: TestIncludeDirectoryOrdering
Change-Id: I9b4e5799d939433da547661b862e9db5a4aacb09
Header libraries don't compile anything, so they don't need the
default stl and libclang_rt dependencies. Trimming the dependencies
simplifies using header libraries for LLNDK libraries, which need
extra variants that don't exist for the default dependencies.
Test: m checkbuild
Change-Id: Ib9864c3cc7048b2cc52acf304830777b65a51877
Modules linking against VNDK R have been using libgcc_stripped and
libunwind_llvm as their unwinder. This change uses those old unwinder
libraries if current module's VNDK version is R.
Bug: 178470649
Test: soong test
Change-Id: I86d0600b2fb09cd9828c0a5b1157558711b0ec86
Link against the libunwind.a shipped with the NDK so it matches what's
linked into the NDK's libc++_shared.so.
Bug: http://b/153025717
Test: device boots, manually inspect some linker command lines
Change-Id: Icc79844f5e70f0eaa97ea758449c30fbddd030d2
For the platform libc++ STL, remove the
-Wl,--exclude-libs,libunwind_llvm.a argument, which is redundant with
the same argument in deviceGlobalLdflags.
Bug: http://b/153025717
Test: device boots
Change-Id: Idd7791d52f74aab2d5f59419fb75f841fc29a2eb
Handling of API levels within Soong is currently fairly difficult
since it isn't always clear based on context what kind of API level a
given string represents, how much canonicalizing and error checking
the code receiving the string are expected to do, or how those errors
should be treated.
The API level struct does not export its raw data, so as to keep its
"constructor" private to the android package, and to prevent misuse of
the `number` field, which is only an implementation detail for preview
API levels. API levels can be parsed with either
`android.ApiLevelFromUser`, which returns any errors to the caller, or
`android.ApiLevelOrPanic`, which is used in the case where the input
is trusted and any errors in parsing should panic. Even within the
`android` package, these APIs should be preferred over direct
construction.
For cases where there are context specific parsing requirements, such
as handling the "minimum" alias in the cc module,
`nativeApiLevelFromUser` and `nativeApiLevelOrPanic` should be used
instead.
Test: treehugger
Bug: http://b/154667674
Change-Id: Id52921fda32cb437fb1775ac2183299dedc0cf20
Bug: http://b/116784799
Previously this was set only when stl was requested. We can now pass
this for all C++ compilations.
Test: go/android-llvm-windows-testing
Change-Id: I43e635ff50d0f1a5e000f13021506aeece368b4a
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
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
Bug: 149075752
Test: tapas com.android.conscrypt com.android.tethering arm64
Test: m out/target/product/generic_arm64/{,symbols/}apex/com.android.{tethering,conscrypt}/lib64/libc++.so
Test: Verified that unwinder was dynamically linked to tethering's
Test: libc++ and statically linked to conscrypt's.
Test: lunch flame-userdebug && m
Test: Verified that unwinder was dynamically linked to /system/lib64/libc++.so
Change-Id: I98eed7cb4316962b19b5c12e150c224c25d0e91d
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
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
libdl.a has a no-op dlopen, which breaks static libraries that need a real
dlopen. Instead of automatically linking libdl.a into static executables,
make it optional.
Until recently, the libunwind_llvm.a unwinder, used on arm32, needed the
no-op dladdr, but it's now built using -D_LIBUNWIND_USE_DLADDR=0.
The HWASan run-time uses dlsym and dladdr, so add a libdl dependency for
HWASan-built static binaries. We could also remove the dependency from
libclang_rt.hwasan_static-*.a, but this is also easy to do.
Bug: http://b/141485154
Test: bionic unit tests, device boots, verify that static and dynamic
executables can throw/catch an exception
Test: verify that a static executable using dlopen doesn't link (unless it
adds an explicit dependency on libdl)
Change-Id: Ic52c3f336b671b4ed335e99c94a64dfe8614b618
Host builds using libc++ used -nodefaultlibs to turn off the default
C++ runtime, and then added back all the other necessary libraries.
Clang supports -nostdlib++ since https://reviews.llvm.org/D47115
that removes the C++ runtime without affecting the other default
libraries. Use -nostdlib++, and remove the lists of default
libraries.
Test: m checkbuild
Change-Id: I722bd6596a1f3f5819f2767c29c0fa1e8b3ec0e8
* 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
libc++demangle provides __cxa_demangle, which used to be a part of
libc++.so but is being moved out to save on resources since very few
libraries need it.
Test: make checkbuild
Bug: http://b/138245375
Change-Id: Ie97225d496d7d40f8749522bf36702a2d9dcdfe7
Bug: 130267141
Test: All system shared libraries do not contain global _Unwind_XXX symbols.
Change-Id: I79673753bb8197041bfe8ffb016d9f5fdf4cada5
Merged-In: I79673753bb8197041bfe8ffb016d9f5fdf4cada5
(cherry picked from commit cf78867417)
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
Bug: http://b/117796718
ucrt is either preinstalled in newer Windows or can be installed in
older Windows, whereas a dependence on msvcr110 doesn't work on Windows
without additional dependencies.
Test: Run generated binaries on Windows VM (7, 8, and 10) without
installing any extra dependencies.
Change-Id: Ibfaea5d78ac85ff4eeed35c97ad8cae4b44dadbc
- Stop including libstdc++ headers.
- '-pthread' and 'static-libgcc' are unused when we pass -nodefaultlibs.
We didn't pass -nodefaultlibs for libstdc++.
- Use SjLj exceptions for 32-bit. libgcc_eh implements SjLj exception
model for 32-bit.
- Disable visibility annotations for libcxx and libcxxabi since we are
only going to support these as static libraries.
- Use Win32 threads. MinGW pthreads throws an error when building
libcxx since it's pthread_mutex_initializer is not constant (needs a
cast).
- Link libgcc_eh, which needs pthread, which in turn depends on
kernel32. Wrap the libraries with --start-group and --end-group and
remove duplicates.
Test: Build and test Windows binaries under Wine.
Change-Id: I8be51b004585e11ef51b7d5012f2a51330d1260f
Bug: http://b/115909626
Some executables linked with msvcr110.a before mingwex.a loop on start
up with the following message:
err:ntdll:RtlpWaitForCriticalSection section 0x7fdcb000 "?" wait
timed out in thread 0009, blocked by 0000, retrying (60 sec)
https://android-review.googlesource.com/c/758688/ has a reproducer.
Test: The reproducer above works, and verify that few Windows binaries
behave correctly (print help message and such).
Change-Id: I837f421532d86f73713d70b3d93609b50d238af9
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 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
libc++'s headers are annotated with availability macros that indicate
which version of Mac OS was the first to ship with a libc++ feature
available in its *system's* libc++.dylib. We do not use the system's
library, but rather ship our own. As such, these availability
attributes are meaningless for us but cause build breaks when we try
to use code that would not be available in the system's dylib.
Test: removed the darwin check and checked showcommands on linux
Bug: None
Change-Id: I3d328d7363eba83f1cb857c8abfd6cd0173a3058
