By Tim Schürmann
Users regularly need just a fraction of the functionality provided by larger applications, such as word processors, for their daily work. To avoid inactive program components unnecessarily hogging RAM - and OpenOffice has over 200MB of this stuff - developers tend to offload them into special files. In Linux, these dynamic libraries are identifiable by their .so suffix. When a user triggers a specific action, the program locates the matching library, loads it into RAM, and runs the requested function. This strategy keeps the applications lean, and to update, you simply install a newer version of the library.
A modular approach like this offers another advantage: Programs can share libraries. An application that gives users a graphical interface can either draw the menus, buttons, and lists itself, or it can rely instead on the Gtk+ or Qt libraries installed in any major distribution. Relying on libraries is very popular because it saves both programming and memory resources.
The drawback to the modular approach becomes obvious when you want to install a new version of the program. First you need to resolve the dependencies on various libraries. This can be very trying for fans of multimedia applications: The software typically relies on numerous libraries, some of which can be fairly exotic - if you have ever tried to install the Kdenlive video editing program, you will know what I mean. As Listing 1 shows, even simple system tools like ls rely on multiple libraries. Fortunately, the package manager typically resolves dependencies quickly and reliably.
Listing 1: Libraries Required by ls |
01 # Libraries required by ls 02 $ ldd /bin/ls 03 linux-gate.so.1 => (0xb8007000) 04 librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7fd1000) 05 libselinux.so.1 => /lib/libselinux.so.1 (0xb7fb7000) 06 libacl.so.1 => /lib/libacl.so.1 (0xb7fae000) 07 libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e50000) 08 libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7e37000) 09 /lib/ld-linux.so.2 (0xb7fed000) 10 libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7e33000) 11 libattr.so.1 => /lib/libattr.so.1 (0xb7e2e000) |
Things start to become more complicated when users try to move an application "quickly" to another machine or run very new software on a legacy system. The variety of Linux distributions is problematic here: To talk the program into running on the target machine, you will need exactly the right versions of required libraries. Even with identical distributions, a minor security update can be all it takes to take out an application you copied to the system previously.
This is where the Statifier and Ermine tools come into their own. They collect the libraries required by an application and glue them together to form an executable. The result is a statically linked program (see the "Static or Dynamic?" box) that will run on more or less any distribution. Of course, the processor architecture could prevent this. For example, a 64-bit application will not run on a 32-bit system no matter what kind of special treatment it goes through. In the other direction, a statically linked 32-bit program will run on a 64-bit Linux version without the need to set up a special 32-bit environment.
Static or Dynamic? |
Libraries are available in static and dynamic variants. As a user, you will never, or very rarely, have anything to do with the former; they are identifiable by the .a suffix and become part of the program at build time. This process is referred to as static linking, and the result is a statically linked program. If you have access to the source code for an application, you could thus build a system-independent program without any assistance from Statifier or Ermine. Dynamic libraries are identified by their .so suffix and are not swapped into RAM until the executable calls the library function at run time. For this reason, the application always needs to include a full set of required dynamic libraries, or it must at least make sure the distribution includes them. |
Statifier [1] is GPL licensed, and prebuilt packages are available for Fedora, Mandriva, and Slackware. The source code archive will work on any other distribution. Make sure you grab the latest version of the Statifier package (not rrp_statify). After unpacking the package on your hard disk, build, and - as an administrative user - install as follows:
# make # make install
The commercial Statifier alternative, Ermine [2], is available in two flavors: Ermine Light, which provides only basic functionality and Ermine Pro, which can include other files besides the libraries. Prebuilt test versions of the two variants are available from the homepage. Download the file that matches your distribution and make it executable. Programs processed with the test versions will run for only 30 days, as Listing 2 shows.
Listing 2: Output from the Trial Version of Ermine |
01 # Output from the trial version of Ermine 02 $ ./ErmineLightTrial.i386 /bin/ls --output=staticls 03 $ ldd staticls 04 not a dynamic executable 05 $ ./staticls 06 staticls: was packed with Ermine Trial and should be used for evaluation only. 07 staticls: license will expire in 31 day(s) 08 ErmineLightTrial.i386 staticls |
To create a portable application, start by investigating the dynamic program that you want to convert. First you need the location and name of the executable program file, which you pass in - along with your choice of name for the statically linked file - to Ermine or Statifier. The following command line tells the latter to create a bundle containing the libraries required by ls, glue them onto the binary, and save the results as staticls.
$ statifier /bin/ls staticls
If you have Ermine, the following one-liner gives you the same results:
$ ./ErmineLightTrial.i386 /bin/ls --output=staticls
The statically linked program is far bigger than the original. Adding the libraries bloats the ls command from a lean 93KB to around 2MB. As Listing 2 shows, the resulting program does not have any dependencies and will thus run on any distribution.
Table 1 compares a few more results produced by Statifier and Ermine. The commercial version of Ermine is typically more efficient than its open source counterpart, although both programs are pleasingly quick. On a Core 2 Duo machine, the modified applications were ready to run in a maximum of four seconds - with just one exception: When I tried to convert the Gnometris game into a statically linked program, Statifier reproducibly went into an infinite loop.
Because the libraries do not need to be located on disk, statically linked programs will tend to run slightly faster, although the difference is hardly noticeable in the case of small tools like ls.
Statically linked programs have their disadvantages, too, of course: For example, you can not install any (security) updates. If a new version of the program or one of the libraries it uses is released, you have no alternative but to run Ermine or Statifier again. Statifier also has trouble with a completely different problem: All modern distributions use stack and address space layout randomization (ASLR) [3]. This involves the Linux kernel assigning a randomly selected section of main memory to each library and program.
The idea is that it improves security and makes attacks more difficult; unfortunately, it also confuses Statifier. As a result, the software can produce unusable programs that collapse with a segmentation fault immediately after launching (see Listing 3).
Listing 3: Segmentation Fault |
01 # Disable Address Space Randomization 02 $statifier /bin/ls staticls 03 $./staticls 04 Segmentation fault 05 $sudo su 06 root@kkissling# echo 0 > /proc/sys/kernel/randomize_va_space 07 root@kkissling# exit 08 exit 09 $statifier /bin/ls staticls 10 $./staticls 11 Images Documents lost+found [...] |
Trouble with openSUSE 11.1 |
On openSUSE 11.1, Statifier reports an issue with the gdb debugger and refuses to create a static version of ls. The workaround I found for this was to disable lines 42 through 46 of the /usr/lib/statifier/32/statifier_dump.sh by inserting a pound sign (#) at the start of each line (you need root privileges for this). After saving the modified file, Statifier did the job without complaining. |
The current workaround is to temporarily disable ASLR. To do so, become a root-equivalent user, write a 0 to the virtual file in question, then output the file to see that the settings are okay:
# echo 0 > /proc/sys/kernel/randomize_va_space # cat /proc/sys/kernel/randomize_va_space 0
Now create the program again with Statifier. Unfortunately, you also need to disable ASLR on any systems on which you want to work with the statically linked version. I will leave it up to you to decide whether this compensates for the vulnerability it creates.
Statifier and the light version of Ermine will only link in dynamic libraries (Statifier will not do this for the critical NSS (Name Service Switch) and Gconv (character set conversion) libraries). However, games in particular typically include material such as images or audio files, whereas application programs tend to offload translations into numerous .mo files. All of these files need to be moved to the new computer. Ermine Pro is the only program to include platform-independent files in the statically linked program. On top of this, the most expensive program in the field can combine multiple programs to create a single statically linked binary.
Because of its many bugs, Statifier is recommended only for smaller command-line tools. Unfortunately, the alternative, Ermine, costs money - how much exactly is open to negotiation with the vendor.
Private users are probably better off putting together a complete Live system. Fedora, Ubuntu, and other distributions include tools to help you build your own system; many rescue disks and other Live systems are also available on the Internet.
INFO |
[1] Statifier: http://statifier.sourceforge.net/
[2] Ermine: http://magicermine.com/ [3] ASLR: http://en.wikipedia.org/wiki/Address _Space_Layout_Randomization |