Listing 134 Build script for dynamically linked Android application

arm-none-linux-gnueabi-gcc -c hello.c -o hello.o <1-

arm-none-linux-gnueabi-ld -entry=main -dynamic-linker /system/bin/linker -nostdlib -rpath /system/lib -rpath-link /android/system/lib -L /android/system/lib -l android_runtime -l c -o hellodynamic hello.o <—© Link Compile only B

g:\tools\adb push hellodynamic /data/ch13 © Copy and change g:\tools\adb shell "chmod 777 /data/ch13/hellodynamic" y permissions

This build script passes the -c compiler option O when compiling the source file, hello.c. This way gcc does not attempt to link the application. The link command, arm-none-linux-gnueeabi-ld, has a number of options ©. These options are more fully described in table 13.1. As in the previous example, adb is used to push the executable file © over to the Android Emulator. The permissions are also modified to mark the application as executable.

Table 13.1 Linker options

Linker option

Description

-entry=main

Indicates the entry point for the application, in this case, the function named main.

-dynamic-linker/system/bin/linker

Tells the application where the dynamic linker application may be found at runtime. The /system/bin/ linker path is found on the Android Emulator, not the development environment.

-nostdlib

Tells linker to not include standard C libraries when attempting to resolve code during the link process.

-rpath /system/lib

Tells the executable where libraries can be found at runtime. This works in a manner similar to the environment variable LD LIBRARY PATH.

-rpath-link /android/system/lib

Tells the linker where libraries can be found when linking.

-L /android/system/lib

Tells the linker where libraries can be found. This is the linker import directory.

-l android runtime

Tells the linker that this application requires routines found in the library file libandroid_runtime.so.

-l c

Tells the linker that this application requires routines found in the library file libc.so.

-o hellodynamic

Requests an output filename of hellodynamic.

hello.o

Includes hello.o as an input to the link process.

If our application required routines from the Open GL or SQLite library, the link command would have additional parameters of -l GLES_CM or -l sqlite, respectively. Leaving those library options off the link command prevents the application from linking properly because certain symbols (functions, data) cannot be found.

So, did it work? The hellodynamic binary is now only 2504 bytes. That's a great improvement. Figure 13.5 shows a listing of the two Hello Android files for a remarkable comparison. Each program is run, first the static version, then the dynamic version.

I c* C:\.WINDOWS\system32\cmd.e)<e -

ddb shell

—rwxrwxrvx root -l'HXrwx^wx root II

root root

3504 2008-0?-568231 2008-07-

■29

04:49 04:21

he llodynamic hellostatie

n ./hellostatic ./hello static Hello, Android! tl

tt tt ./hellodyneimic ./hellodyncuiic Hello, Android! [1] Killed tt

./hellodynamic

Figure 13.5 Hello Android, static and dynamically linked

Figure 13.5 Hello Android, static and dynamically linked

This looks great, except for one little problem. Note the last line in figure 13.5, which says, "Killed." Is there a problem with our dynamic version? Let's look closer.

0 0

Post a comment