These files have the same case-insensitive name, and this creates problems
when used on Windows + Cygwin.
Change-Id: I911906c209ad9fca8752ba4cdc9c65abdd0bd4a9
You can now define LOCAL_ARM_NEON to 'true' in your Android.mk
to indicate that a whole module must be compiled with NEON support.
Alternatively, use the .neon suffix when listing source files in
LOCAL_SRC_FILES to indicate that they should be built with NEON
support. E.g.:
LOCAL_SRC_FILES := foo.c.neon bar.c zoo.c.arm.neon
Note that .arm.neon is supported, but .neon.arm is NOT.
Also added documentation in docs/CPU-ARM-NEON.TXT
Another patch will provide one or more sample applications
to demonstrate all of this.
It is provided as a static library that NDK developers can link against.
The code is designed to run on all official Android platforms, starting
from Android 1.5.
This is needed because upcoming Cortex-A9 devices implement
VFPv3-D16 instead of the assumed VFPv3-D32 and have thus half
the floating-point registers.
Only touches download-toolchain-sources.sh and build-toolchain.sh
This does not impact the NDK build scripts themselves and is only
needed to properly package NDK release packages.
Ensures that no stale/obsolete shared libraries are left in the
application's project path before the build.
Also fix a minor typo that made the ABI selection process not
work properly in certain cases.
This patch modifies the NDK build scripts to support the 'armeabi-v7a' ABI.
(For the record, it corresponds to Thumb-2 + FPU support, to speed up native
code on certain devices like the Droid).
To build for this ABI, the Application.mk file should use a line like:
APP_ABI := armeabi-v7a
It is also possible to build for both 'armeabi' and 'armeabi-v7a' by using:
APP_ABI := armeabi armeabi-v7a
This will result in the generation of two distinct shared libraries that both
will be copied to the final application package.
This is dependent on having GCC 4.4.0 prebuilt binaries under
build/prebuilt/<host>/arm-eabi-4.4.0, since gcc 4.2.1 does not support
this new ABI.
Note that this also changes the NDK to use gcc 4.4.0 by default, unless
the user defines NDK_TOOLCHAIN to 'arm-eabi-4.2.1' in its environment to
switch back to the previous one.
This patch modifies the script to be able to build all prebuilt toolchain
binaries in a single call. I.e. if passed a recent toolchain source package
generated with download-toolchain-sources.sh, then it will build both
GCC 4.2.1 and GCC 4.4.0 and place them in the final prebuilt tarball.
We need this because, while we're going to switch to gcc 4.4.0 by default
in a new version of the NDK, the 4.4.0 C++ compiler is more strict about
various constructs and might refuse to build certain sources. An option
will be given to application developers to use 4.2.1 instead, to keep their
sources building.
Other changes include:
Move all builds into a random temporary directory under /tmp by default,
unless you use --build-out=<path>.
Cleanup the build out directory on succesful build
The generated tarball is now named android-ndk-prebuilt-<date>-<host>.tar.bz2
by default, unless you use the new --release=<name> option which will replace
<date> with <name> instead.
Removal of un-needed files (e.g. info or man pages, libiberty static library,
etc..) to reduce the size of the final tarball.
Update the script used to build the prebuilt toolchain binaries.
There are now two ways to use it:
1/ As usual, just invoke it and it will download the source tarball,
uncompress it, configure the toolchain sources, build them, then
package the result into a 'prebuilt' tarball.
2/ Generate a new source tarball with the 'download-toolchain-sources.sh'
script, and invoke build-toolchain.sh with the --package=<tarball>
option.
Additionally, you can now specify --gcc-version=4.4.0 to build GCC 4.4.0
(with ARMv7 / FPU support)
The option --gdb-version=6.8 has been added but the build doesn't seem
to work yet. This will probably be fixed in the toolchain git repository
though.
This will be used to refresh the NDK with gcc 4.4.0 prebuilts and support
for armeabi-v7a soon.
download-toolchain-sources.sh will download the current toolchain sources
from our git repositories then finely package them into a compressed
tarball that will later be used to rebuild the prebuilt binaries properly.
Due to the way our sources are stored in the git repository, the sources
in the tarball are laid out slightly differently than in the original toolchain
source archive used for NDK 1.6.
An upcoming patch will modify build-toolchain.sh to deal with the difference
and also allow the build of gcc-4.4.0 and gdb-6.8.
For now, this is an exact copy of android-4. Another patch will
provide additionnal headers and libraries for OpenGL 2.0 plus
the relevant documentation bits and a sample app.
E.g. if an application's default.properties targets android-10
then the build system will default it to the highest supported
API level found in build/platforms (e.g. android-4 currently).
There is little point to use symlinks to point to them from
android-*/arch-arm/usr/include. Besides, the zip file format doesn't
support symlinks which meant that each file was essentially
duplicated in the final release package.
This is used to help people easily package experimental versions of the NDK to
test and distribute fixes and improvements. The main idea is to allow external
contributors to play with it in interesting way and share the result easily.
The main idea is that libgcc.a should appear after object files and
static libraries but before depending shared libraries. This willl
force the linker to copy the libgcc.a functions required by the
generated library into the target binary, instead of relying on
what's available in libc.so and others.
This ensures maximum portability, and prevent problems in the future
when we change the toolchain, which translates to different libgcc.a
functions embedded in libc.so and other exposed native libraries.
However, this will make also generated shared libraries bigger, because
the compiler insists on generating code that depends on a bunch of C++
support functions (even when building from C sources). An increase of
about 8KB per shared library is expected.
This gets rid of the 'sources' directory and allows all sources
of a given Android application to be in the same directory tree
without using a symlink trick.
Note that apps/<name>/Application.mk is still required though.
A later release of the NDK will get rid of it too, but the change
is too drastic for the upcoming release.
The change moves various source files from sources into their
app/<name>/project/jni directory as well.
The whole documentation is updated to reflect the change.
Note that the app will only build against an android-4 SDK.
(Interestingly, the resulting binary runs very well under android-3).
This also adds missing license headers to the 'two-libs' sample.
- generate thumb code by default (type forced ARM generation)
- make the generation of unoptimized binaries with APP_OPTIM := debug actually work
(the -O0 -g flags were placed before the -Os -mthumb flags for thumb binaries)
- factor common code from build-executable/shared-library/static-library into build-binary.mk
and install-binary.mk
- properly add a -L$(SYSROOT)/usr/lib line to make LOCAL_LDLIBS := -lz work as advertized
(in build-binary.mk)
- add a few missing variables from clear-vars.mk
- run as bash script (since Debian's new 'dash' shell doesn't support it)
- remove obsolete host GCC requirement
- improve Windows support by using better heuristics for the executable suffix
- better NDK root directory auto-detection (avoids the need to define ANDROID_NDK_ROOT on some installs)
