Commit 28acbeab18f6083299c07f9ebe769d22e49f8107 removed the dependency of
sepolicy-analyze on libc++, eliminating the only consumer of the library for the
cts host-side tests. Remove the library since it is no longer needed but leave
the ability to add other shared libs in the future.
(cherry-pick of commit: 214a171424)
Bug: 19566396
Change-Id: I36f45c3e92c2d6370e98baa4c527835af66691fa
ASan runtime library (when using dynamic linking) must be the first
dependency of the main executable to achieve correct symbol
interposition. This matches how the clang driver works.
In multilib setup, ASan-RT name depends on the target arch:
/system/lib/libclang_rt.asan-arm-android.so
/system/lib64/libclang_rt.asan-arm64-android.so
We also set RPATH to /system/lib/asan or /system/lib64/asan
to have a place for ASan-only versions of system libraries.
Change-Id: I937d202077b6e433ba476c075d31be818b662d53
Always link libm with asan. Hasn't been a problem before because ASAN
was only ever used when libc++ was as well, which already links libm.
Pass --no-as-needed for host modules.
These aren't needed for the target builds because the target uses the
shared RTL.
Change-Id: I3b95c8682c0f63bac6b726f8cd15c638aaa98311
The only remaining users of stlport are vendor blobs. Prevent any new
users from using it.
Bug: http://b/15193147
Change-Id: I577a16c8c52e2c7d939c3b5026e18ad90e4b9f26
(cherry picked from commit 3a360a7353)
- Detect java-source-list before transforming to java-source-list-uniq.
This fixes non-fatal errors in build log like:
/bin/bash:
out/target/common/obj/APPS/android.core.tests.libcore.package.tzdata_intermediates/classes/java-source-list:
No such file or directory
- Cleaned the outdated incrementaljavac. Nobody is using this feature
and now we switched to jack.
Change-Id: If1adb9b5820d9b295a11984c0f170f9a7ff4de7b
Also filter out gcc-only flags -Wno-clobbered and -fno-devirtualize
when compiled with clang/llvm.
BUG: 19872411
Change-Id: I6de57583be04da607f569df65e93531787dbb789
(cherry picked from AOSP commit 90036610dd)
When an app's LOCAL_SDK_VERSION is lower than the support library's
LOCAL_SDK_VERSION, we artifically raises the "SDK version" "linked"
by ProGuard, to
- suppress ProGuard warnings of referencing symbols unknown to the
lower SDK version.
- prevent ProGuard stripping subclass in the support library that
extends class added in the higher SDK version.
This allows us to remove the dangerous ProGuard flag
"-dontwarn android.support.**".
Notes:
- We don't raise the app's LOCAL_SDK_VERSION, so that the app's own
code is still unable to use the higher SDK version.
- For platform build, we can't just raise to the "current" SDK,
because would break apps that use APIs removed from the current SDK.
We raise it to framework.jar instead, which contains the most complete
symbol set.
Bug: 20658265
Change-Id: I90099073457a65cb8031fbaec6b396d68ce614a7
(cherry picked from commit 8e8d1e7aba)
We need PT_LOAD segments to match for the gdb sake.
If we pack module after stripping symbolic version
PT_LOAD differ from actual ones; this confuses gdb.
Bug: http://b/20687795
Change-Id: If7b1ffcda918d0cc47051a30ca1202007ed62403
Enable the following compiler hardening flags:
* -Wl,-z,relro
* -Wl,-z,now
* -fstack-protector
relro / bind_now make the relro region read-only after linking,
preventing certain attacks against ELF data structures.
stack-protector adds stack canaries, which can detect exploits
which overwrite parts of the stack.
Explicitly not added in this change is FORTIFY_SOURCE=2. Adding that
option turns on glibc's warn_unused_result attributes. This generates
a huge number of new compile time warnings, and for the multiple
makefiles which have -Werror in them, turns those warnings into errors.
I'm not able to fix all the errors right away.
Bug: 20558757
Change-Id: I86791177c6695f5325233d9dd9a5dd3ccc2b1a2f
Filip Gruszczynski