The static flag revisited

When an application is built with the -static flag, it is entirely self-contained, meaning that all of the routines it requires are linked directly into the application. This is not new information; we have already discussed this. It has another important implication beyond just the size of the code: it also means that using Android resident code libraries is a bigger challenge. Let's dig deeper to understand why. In order to do this, we have to look at the filesystem of Android/Linux.

System libraries in Android/Linux are stored in the directory /system/lib. This directory contains important functionality, such as OpenGL, SQLite, C standard routines, Android runtime, UI routines, and much more. Figure 13.3 shows a list of the available libraries in the Android Emulator. In short, everything that is specific to the tt Is ✓system/lib

Is /system/lib security libdl.so libthread_db.so libc-so libra, so libstdc ++.so libs.so libcutils.so libexpat-so libcrypto.so libicLidata. so libuorbisidee .so libsonivox.so libdbus.so librpc.so libadsp.so libaes.so libeucnt.so libctest-so libGLES_CM.so libssl.so libutils.so

1ibicuuc.so libdrml.so libreference—ril.so libicuilSn.so libcoreeg.so

1ibmedia.so libpim.so libril.so

1ibdrmlni.so libhardware.so libsqlite-so libpixeIf linger.so libaudioflinger.so libsgl.so libnat iueheIper.so libLIAPI_jni.so libagl.so libui.so libdvm.so libsurf aceflinger. so libandroid_runt ime.so libsystem_seroer.so libPPTEm.so libpM.so libpudounloadreg.so libmedia_jni.so libpurtspreg.so libpunet_support.so 1ibpv do wnlo ad.s o libpurtsp.so libwebcore.so « _

Android platform is found in /system/lib, so if we are going to build an application that has any significant functionality, we cannot rely on the libraries that ship with CodeSourcery alone. We have to write an application that can interact with the Android system libraries. This calls for a side trip to discuss the functionality of the linker application.

When building an application that requires the use of the linker, a few things change. First, the gcc command is no longer responsible for invoking the linker. Instead, the -c option is used to inform the tool to simply compile the application and leave the link step to a subsequent build step. Here is an example:

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

This command tells the compiler to compile the file hello.c and place the resulting object code into the file hello.o.

This process is repeated for as many source files as necessary for a particular application. For our sample application, we have only this single source file. However, in order to get an executable application, we must employ the services of the linker.

Another important change in the build environ- Figure 13.3 AVailable libraries in / ment is that we need to get a copy of the Android/ system/lib

Linux libraries. We are compiling on the Windows platform (or Linux if you prefer), so we need to get access to the Android Emulator's /system/lib contents in order to properly link against the library files. Just how do we go about this? We use the adb utility, of course! Listing 13.3 shows a Windows batch file used to extract the system libraries from a running instance of the Android Emulator. A few of the libraries are pointed out.

0 0

Post a comment