On some Linux distributions (spotted here on OpenMandriva Lx, but I'm
pretty sure some others do the same thing), "which javac" returns
/usr/bin/javac, which is a symlink to "../../etc/alternatives/javac",
which in turn points at whatever the JDK the user picked as his default.
Given "../../etc/alternatives/javac" is a relative, symlink, the next
iteration of LSLINE=$(ls -l "$JAVAC") fails (no
../../etc/alternatives/java relative to the build directory), causing
tools.jar not to be found.
Using readlink -f should work in all cases (while also simplifying the
script a bit).
Change-Id: I96afcf8e6460861bf8bb849dae05c27c42b91e84
Signed-off-by: Bernhard Rosenkränzer <Bernhard.Rosenkranzer@linaro.org>
The dalvik.vm.* properties are in PRODUCT_DEFAULT_PROPERTY_OVERRIDES,
not PRODUCT_PROPERTY_OVERRIDES.
Use $(call func,args) for user defined functions
Prepend the property contents with -Xms or -Xmx when passing to
dex2oat. This only worked before because DEX2OAT_XMS, etc. were blank
due to the first two bugs, which resulted in --runtime-arg --runtime-arg
and anything starting with -- as the argument to --runtime-arg is
silently ignored.
Change-Id: Ifa30038b397355171fefcc5248eea033bb634036
Set up TARGET_IS_64_BIT and HOST_IS_64_BIT early so we don't need 2
mechanisms to judge if it's 64-bit build;
Remove the unnecessary 32-bit host variables.
Change-Id: I08d6d4d9ea70f91135fe2ee05463fb9a0d1cee42
In droiddoc for host, we don't generate classes.jar for
LOCAL_JAVA_LIBRARIES. Switch to refer to the installed jar file instead.
This is consistent with how LOCAL_JAVA_LIBRARIES for host is handled in
base_rules.mk.
Bug: 9176318
Change-Id: If7460b30ca5da28743487d66da0029a44108d556
-fPIC is more restrictive than -fPIE, but when "-fPIC -fPIE" used together
the latter overrides. It may lead to issues when building DSO where
-fPIC and not -fPIE is required.
For executables -fPIE -pie shoudld be added and it's fine to override
-fPIC as it is done now.
The reason why we don't have these issues so far is probably related to
-Bsymbolic added by default. But any attempt to remove it reveals these
problems:
https://android-review.googlesource.com/#/c/98061/
Change-Id: If0f10628b7cc41e564221a7a37298f7d65f859a8
Signed-off-by: Pavel Chupin <pavel.v.chupin@intel.com>
This was expanding to TARGET_VENDOR_OUT_SHARED_LIBRARIES which was
empty. It should be expanding to TARGET_OUT_VENDOR_SHARED_LIBRARIES.
Change-Id: I32fe22e3e0b91a6d41f6a09a33d3ce2e4061d078
In 64-bit multilib host build, changed from
32-bit lib: out/host/<platform>/lib32
64-bit lib: out/host/<platform>/lib
to
32-bit lib: out/host/<platform>/lib
64-bit lib: out/host/<platform>/lib64
.
That way the host library path is consistent with the multilib target
build's. Also with this change prebuilt 32-bit libraries can be reused
in 64-bit host build as 2nd arch binaries. (With previous setup, they
can't be used because they have rpath ../lib in it while the 2nd arch
library path needs ../lib32.
Change-Id: I020199d0c7dd52cdc8dcb7d3a1d22cd6178672e1
Some packages can override list of locales with
LOCAL_AAPT_INCLUDE_ALL_RESOURCES parameter, disabling
pseudolocalization. Adding new --pseudo-localize flag to
aapt if pseudo-locales are specified in product locales
list solves this issue.
Change-Id: Iae705d4fe99453650339fd1ca65d1005671b3e4f
Use "LOCAL_MULTILIB := both" to install jni libraries of both archs in
multilib build.
The build system will package jni of both archs to the apk, or install
them to the right location on the system image and create symlinks,
extract .so files from prebuilt apk, etc if appropriate.
Bug: 15849902
Change-Id: I7e147b5a47db476584c38250de7b36c75ea40d81
