Previously, old GNU linkers were removed, in favor of the LLVM linker
lld. However, old versions of AGP consider the absence of those linkers
to mean that the build tools are corrupted. To solve this problem, we
provide a (non-executable) dummy file in place of each old GNU linker to
keep AGP satisfied. A compatibility mode RenderScript build by those
old versions of AGP will fail (as it would have without the dummy
files), but everything else should work.
Bug: 153685081
Bug: 144040336
Bug: 142590626
Test: (gLinux) m TARGET_PRODUCT=sdk_phone_armv7 TARGET_BUILD_VARIANT=userdebug sdk dist sdk_repo
(gLinux) m TARGET_PRODUCT=sdk_phone_armv7 TARGET_BUILD_VARIANT=userdebug win_sdk dist sdk_repo
Change-Id: I7574c850bfb593df5bcb9131ea8915061b0083e1
Linkers aarch64-linux-android-ld and x86_64-linux-android-ld were built
with a minimum macOS deployment target lower than 10.9, so they cannot
be signed and notarized. Rather than try to produce newer versions of
these linkers (which are obsolete in the SDK anyway), we remove them (so
that all of the SDK can be signed and notarized). Rather than introduce
an inconsistency among the linkers for a particular host (there are
three other GNU linkers that don't have this problem) or across hosts
(there are no issues on linux or windows), we remove all of the GNU
linkers, not just the two problematic ones.
Only newer gradle plugins (those that look for the clang linker lld)
will work with the new SDK from which those old linkers have been
removed.
Bug: 152337684
Test: (gLinux) m TARGET_PRODUCT=sdk_phone_armv7 TARGET_BUILD_VARIANT=userdebug sdk dist sdk_repo
(gLinux) m TARGET_PRODUCT=sdk_phone_armv7 TARGET_BUILD_VARIANT=userdebug win_sdk dist sdk_repo
Inspect sdk-repo-{linux,windows}-build-tools-eng.*.zip
Change-Id: Iccfa870a826de3f12c99175e0761ea00fe2876ed
prebuilts/sdk/tools is updated from the zip file built by the SDK.
The lld binaries are copied from the prebuilts to the zip file, and
were moved in the zip file, which meant the next time the prebuilts
were updated the wrong files were copied.
Fixes: 151729229
Test: m TARGET_PRODUCT=sdk_phone_armv7 TARGET_BUILD_VARIANT=userdebug out/host/linux-x86/sdk/sdk_phone_armv7/repo-sys-img.xml sdk sdk_repo
Change-Id: I2de182f3cbf739dbd9c6a5287e1416ea37d2899f
darwin: Move lld to lld-bin directory; add lib64/libc++.1.dylib; add trampoline
linux: Move lld to lld-bin directory; add lib64/libc++.so.1; add trampoline
Best practice is to ship necessary libraries of expected versions along
with build tools, rather than requiring them to be found elsewhere.
lld depends on libc++.1.dylib (darwin) or libc++.so.1 (linux) and looks for it
in ../lib64, so we need to move lld to an appropriate relative location.
In the old location of lld, we add a simple bash trampoline to invoke
lld in lld-bin; this means Gradle, which invokes lld in the old
location, does not have to change.
Bug: 148267171
Bug: 142590626
Bug: 144040336
Test: (gLinux) m TARGET_PRODUCT=sdk_phone_armv7 TARGET_BUILD_VARIANT=userdebug sdk dist sdk_repo
(gLinux) m TARGET_PRODUCT=sdk_phone_armv7 TARGET_BUILD_VARIANT=userdebug win_sdk dist sdk_repo
Change-Id: I69b4ef79208bd7d06a377c0761671f1b572abced
Note that clang linker is multi-target whereas GNU linker is
single-target; so while we need multiple GNU linkers (because we
support multiple targets) we only need a single clang linker.
We retain the GNU linkers so that a new SDK is still compatible with
older gradle plugins.
Bug: 142590626
Bug: 144040336
Test: (gLinux) m PRODUCT-sdk_phone_armv7-sdk dist sdk_repo
(gLinux) m PRODUCT-sdk_phone_armv7-win_sdk dist sdk_repo
Change-Id: I2a04f6fd464b5eb6a2e9a632f49409c1d7e60170
The LLVM libraries used for RenderScript have been changed to include
the "_android" suffix.
Test: make PRODUCT-sdk_x86-sdk dist sdk_repo
Change-Id: If328eac65c78877d608f097ec18f6197a17df804
The rpath for the binaries is ../lib but the libraries were being
installed to the same directory as the executables.
Bug: 19617220
Change-Id: I5c4158698b6703843b67543d4396e2bffc5fb313
This allows the mainDexClasses to work by
finding shrinkedAndroid.jar and proguard (from
the SDK Tools folder) correctly.
Change-Id: Ib3d85f775876b8a487af04bd072f6d8877f31d3b
Add the script to run multi-dex manually in build tools
Update non-maven support package to .0.1 to release a version
with the fixed multi-dex support lib.
Change-Id: I78c84e0d999855f9fc20fadfa21647e570a9f8c9
The new llvm-rs-cc compiler is not statically linked
anymore so those libraries are needed.
Also add the new support stuff.
Change-Id: I4d56f0b07f0f0f120b512726689ae4ff07f38322
The output of the platform tree build is llvm-rs-cc-2 and should
be used for apps targeting 12+. This is encoded in llvm-rs-cc.txt
The older (HC) version of llvm-rs-cc is copied from the prebuilt
and is used for apps targeting 11+.
Until new tools that can read/process llvm-rs-cc.txt are released,
old tools will use the HC version of llvm-rs-cc which ensure
proper compatibility.
Change-Id: Iddb924409cc9238531bf1a0448b14b7eac3396a5
This depends on another CL in prebuilt that packages
both linux-x86/swt/swt.jar and linux-x86/swt_64/swt_64.jar:
https://android-git.corp.google.com/g/5178
The new jar are picked from out/... rather than prebuilt,
which seems to work better.
The SDK now contains 32 and 64 bit version of SWT. DDMS and Traceview
use the archquery java app to check the architecture of the VM to decide
which version of SWT should be used to run the apps.
