How Programs Work on Linux

For Linux, one thing that makes a program is that the file has its execute bit set. Without the execute permission bit set, even a compiled program will not be executed by the Operating System. ie:

In an interpreted script, what makes a program executable is the presence of the shebang line pointing to the interpreter that you want to process the program. In the Perl example above, the shebang line was the 1st line, which is prefixed by a hash and an exclamation sign (or bang in geek). Hence shebang.

Often, files will be chmod'ed to be executable, when they aren’t valid programs.

A file can’t be executed simply because the execute bit IS SET, but NOT having the execute bit set will prevent a program from running by calling its name. However, you CAN still execute a program that does not have the execute bit set by prefixing the name with the appropriate interpreter.

If irvinepines.pl is an otherwise functional perl program:

Note that whether it is executable depends on the execution bits (as well as whether it’s a valid program).

The above example holds true for most interpreted scripts, but not for compiled programs. ie you can’t cause a compiled program called tustintrees to execute simply by prefixing the name with a compiler. gcc tustintrees will not work.

The Perl (or Python or R) script is a file containing human-readable ASCII characters that the Interpreter can translate dynamically into executable code.

Creating a compiled program starts with writing the source code which looks similar to a script, except that it doesn’t begin with a shebang line. Here’s a very short C program

There are more lines than in the Perl script above and there’s much more to the creation of the executable code, but rather than duplicating Google, let me reference a page that describes it well. That link describes a process that you probably don’t need to know at this stage.

There are a number of utilities that aim to make building programs easier. The most widely used are based on the make utility, a system that calculates dependencies and allows you to re-run only those part of the dependencies which have failed. In addition, it can run these builds in parallel which can tremendously speed up large compiles, especially when you’re in the debugging stages. See the section above for more info on generating usable Makefiles.

There are several systems that use Makefiles. The 2 most widespread are GNU make and CMake, tho they use Makefiles in different ways; GNU Make consumes Makefiles (typically produced by the autoconf toolchain) and CMake produces Makefiles to be processed by Gnu Make in the same way that it consumes Makefiles produced by other mechanisms.

Because Java is a hybrid system (usually partly compiled, partly interpreted), it uses tools from both the Interpreter world and the Compiler world. Ant, Maven, Gradle, and Gant are systems that work like Make/CMake, but are specific for Java, most often because of the multi-file aspect of Java and the startup time of the Java Compiler javac. C/C++/Fortran tends to have a flatter structure with fewer files and therefore work well with make/CMake. However Java projects tend to have lots of small files and calling javac on hundreds of small files has a substantial overhead. Ant/Maven and friends discover all the dependencies and requirements and call javac on all the files at the same time, sparing the file-by-file startup times.

Rake is a make system for Ruby, another interpreted language.

The preprocessor examines the preprocessor directives in various languages (the statements in C/C++ prefixed by "#" such as #define, #include, #undef, etc) and resolves them, notably the #include statements that point to the header files (*.h) that define interfaces for all external functions.

A lexer is a program that generates tokens (scans a series of characters and extract and assigns values to them) as part of determining how a program should operate. For example, the process of determining the options fed to a program would require such lexing. See Wikipedia for more examples.

The parser often operates with the lexer to automatically generate the code to process the lexer tokens. Because of what it does, it’s often referred to a compiler compiler - it generates the structures and formalism to process an arbitrary language into computer code. The lexer and parser are often used in option processing and especially to generate the language parsing that an internal language or commands that a complex program might use. Gnuplot and all interpreters would require such functionality. ie, in Gnuplot, the lexer/parser would enable you to write routines that differentiate between plot and plod.

The linker ld is the program that resolves all the function calls to either code you wrote or to functions in the system libraries and imports them either entirely (in a static linkage) or a reference or symbol (in a shared or dynamic library linkage). Read more at Wikipedia. The Loader also is responsible for starting the program, by loading it into RAM, notifying the kernel that a new process is running, resolving symbols & functions, requesting memory to run in, and making sure that the process obeys the rules for execution.

ldd helps to debug program failures due to missing shared libraries. If a program cannot find a necessary library, it will fail; ldd will identify the missing library and possibly provide hints to where it should be. (see also the RPATH environment variable)

Quite often, especially when you’ve copied a shared application from another Linux distribution, you will find that it complains about missing libs when you know that you already have that library or you have a similar lib that may be a version higher or lower than the specific one demanded.

If you know that you have the missing lib, your current LD_LIBRARY_PATH is probably missing or misconfigured. You can determine if this is so by first locating the missing lib and then checking the value of LD_LIBRARY_PATH. If the missing lib is called libpcre.so.3.12.1, try:

The envar LD_LIBRARY_PATH is not set, so the system is relying on the default set of paths set in the files in /etc/ld.so.conf.d. These files are editable by root, so if you have your libs in a non-standard location, you can include it by editing those files and then running ldconfig which will add the libraries therein to the cache.

If you wanted to add the lib above to the LD_LIBRARY_PATH, you can by explicitly setting it:

The application would then be able to find the missing lib and execute (at least to the next failure).

You can often fake a fix if you don’t have the specific lib for which the application is looking. Linux libs tend to be very conservative, so that if you need libpcre.so.3.13.2 and you have libpcre.so.3.12.1, the application may very well be able to work just fine. All you need to do is provide a symlink to the older lib.

GLIBC is the Gnu Standard C library. It’s part of every Linux distribution and is very stable. However, if you build a program on one Linux system (especially a modern one, such as your laptop) and then copy that application to an older system (a cluster or larger system that may not be as up-to-date as your laptop, you’ll often see this error:

This is due to having a GLIBC compatibility problem. GLIBC is always backward compatible (so you can always run an old program on a newer system) but can’t be forward compatible (so running a new program on an old system will often yield this error. There are 2 somewhat easy solutions and one more difficult one. The easiest solution is to recompile your program on your laptop as a static executable. That will force your program to carry with it all the functionality that it will ever need. The other somewhat easy alternative is to re-compile your program on the old system, which will resolve all the symbols into the older GLIBC. The harder alterntive is to provide your current shared program with the correct GLIBC version by running it in a chroot environment that has the correct GLIBC. There are more sophisticated mechanisms for doing this as well, but I’m not going to address them here.

PATH defines where the OS looks for executables. A default PATH is set when you log in, typically something like:

which prepends my (hjm) private bin dir in front of anything else. PATH can be expanded and modified arbitarily. Here’s what my laptop PATH looks like.

It can also be changed programmatically to point to alternative applications, especially in large systems that might use something like the environment modules or lmod systems, which also manipulate the following variables to the same end.

LD_LIBRARY_PATH defines the directories thru which the loader will search to find shared libraries. The following demonstrates the changes a module load can have on the LD_LIBRARY_PATH.

RPATH is the search path hard-coded into a library when it’s built, to point to required libraries needed to resolve missing symbols. Because it’s hard-coded, it’s a fairly fragile mechanism for resolving such symbols and it generally better to use the LD_LIBRARY_PATH to point to library locations. If you have to use it, you can define the envar LD_RUN_PATH to be read by the linker ld or supply it explicitly with -rpath=/path/to/libraries.

LDFLAGS is an envar that often contains both the -lname and -Llocation of the libraries that need to be found in order to satisfy the compilation (and so can partly replace the LD_LIBRARY_PATH in the compilation phase, but NOT in the execution phase).

The name is constructed like: -l*name* where name is the diagnostic part of the library. So if the library was named 'libgomp.so.4.5, the LDFLAGS abbrieviation would be -lgomp. The specification of the -lname is also often associated with the envar LIBS, depending on who is writing the code.

The location of the library is specified in LDFLAGS with the prefix -L/full/path/to/lib/dir

CPPFLAGS is used to provide paths to header (*.h) files that are not on the standard include path (usually /usr/include). The format used is similar to the LDFLAGS above:

MANPATH is simply the path that the man program should search in order to find the man pages for an entry.

Describe the use of print/printf in debugging

Associated with the __LINE__ CPP var.

The Gnu Debugger is awesome and awful.

ddd puts a friendly face on gdb.

The monster memory monster debugger.

The warning about premature optimization Don’t engage in optimization until you find out where your program is spending time.

These mechanisms are highly preferred for personal installation since they can be used to install scripts, programs, libraries, configuration files, and can also set up the installation, alias, and initialization files. They often cannot be used on large multi-user systems since they require root permissions that a normal user won’t have on a large system.