We don't have separate *64 module names any more.
Now both 32-bit and 64-bit variants are built under the same module name.
Change-Id: I1956a6a88ec6fe280798be01928239d098dfe27a
Dx is now capable of generating multiple dex file in one run.
This capability is not compatible with --output=*.dex so this CL
changes the --output argument to be a directory. This CL also
includes the packaging of the multiple dex files when dx generates
more than one dex file.
(cherry picked from commit 8ffe9c3e79)
Conflicts:
core/java.mk
Change-Id: I1ddc91b416de5929d4d4b41824c6012b32f94deb
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
