happens when you run a program? Ever downloaded software from the Net that didn't work, even though it may have compiled and installed correctly?
If the answer to either of these questions is yes, you probably want to know more about how Linux runs programs. Even if you can't say yes to either of these questions, you'll undoubtedly be curious.
In this section we'll look at how a program starts up when it is run from the command line. We won't deal with running a program from a menu pop-up in X, as this depends on which window manager you're using.
You're at the console and you type foo and then press Enter. One of two things will happen: the shell will print out a message saying that the command foo' was not found, or it will run a command, foo.
When asked to run a command like this, Bash takes a number of steps to figure out what to do. First it checks whether the command is a built-in Bash command like while, for or if (to see a list of all the inbuilt commands type man while at the prompt). If the given command was not a built-in command it then checks if it is a Bash alias or function. Aliases and functions can be defined at the command prompt or in one of the Bash initialisation files; either the peruser ones (~/.bash_profile or -/.bashjogin) or the global one (/etc/profile).
If the command foo was not found in any of the above steps, Bash then looks for the command in the directories listed in the PATH environment variable. Finally, if it could not find the given command in any of these directories Bash will print out the dreaded 'bash: foo: command not found' message.
If foo does exist and the person running Bash has execute permissions for the file, Bash will execute it. Inside the Linux kernel, there is some code to figure out how to run the file. For instance, the file may be an ELF executable or a script for one of the many scripting languages common on Linux. If foo is a script, the kernel will find the script interpreter's name in the first line of the file (such as '#!/bin/bash') and start the interpreter, passing it the name of the script it has to execute.
If, on the other hand, foo is an ELF executable, then it's much more complex. Firstly, there are dynamically and statically linked ELF executables. Statically linked executables are completely self-contained and do not need any external libraries to run. When a statically linked binary is running, the debían hardware I networking I security I maximising I developing I helping
WHAT'S THIS ABOUT ELVES?
ELF is an acronym for Embedded Linking Format and is really just a specification for how a binary program is packaged. An ELF binary contains information about what part of the binary is code, what part is static data (such as test strings which are printed out) and so on. A binary can also contain things such as debugging information which the GNU debugger gdb requires to display the source code of the program while it is being debugged.
only time it executes code outside of itself is when it makes a system call. A system call is a call into the Linux kernel to perform tasks like opening, reading or writing a file, starting another program, getting process information or any of a number of other tasks. Library calls are similar in many ways but pure library calls do not need to enter the Linux kernel to complete their required operation.
Dynamically linked executables, on the other hand, do use code from external libraries, which are shared with other programs, to perform some of their work. There are a number of advantages to this. Firstly, it means the program will take up less disk space because part of its code is stored elsewhere. In addiipfT? the application programmer's job is easier as they can use code written and debugged by someone else instead of writing it themselves from scratch. More importantly, it reduces the usage of system memory.
Consider three programs all running at the same time and all linked to 'libxxxx.so'. This library will contain code, static data such as strings and constants and data that is modi fied during the running of the library code. The Linux kernel will only load the code and static data sections of this library into memory once, but it will give all three programs access to it. The only part of the library which will have to be replicated is the dynamic data section; the part of the library that changes during its running lifetime.
You might already have seen packages such as 'gnome-libs' and 'kdelibs'. When you install a new Gnome or KDE program, it can't run without the Gnome or KDE libraries installed as it calls on these to perform certain functions — such as loading a file save dialog or drawing buttons a certain way. In fact, even KDE itself was built with the QT toolkit — a set of libraries that provide GUI functions to help make producing an interface a breeze. Hence, to run a KDE program you need the KDE and QT libraries installed.
When the Linux kernel reads the headers of a program and detects that the program is a statically linked executable it simply runs the program. However, for a dynamically linked program it needs to
Was this article helpful?