# GLPK/Linux OS

This page explains how to build and install GLPK on a Linux operating system. The standard compiler suite on Linux is GCC. Notwithstanding, other compilers can be installed and used.
Pre-packaged option: as an alternative, GLPK may also be available as a Debian (used by Ubuntu) or RPM (used by Fedora) package. Installing a package is more convenient than compiling, but packages tend to lag behind by one or more releases. Manual compilation also allows you to customize your build configuration so that the resulting library can better match your circumstances and needs.
New users are therefore encouraged to build GLPK from source. Assistance, should you need it, is always available from the help-glpk mailing list.

## Key files

The key GLPK files in relation to Linux are shown in the following table:
| File | Role | Default | File |
| glpsol | command-line solver | /usr/local/bin | executable file |
| glpk.h | GLPK API header | /usr/local/include | C language header file |
| libglpk.a | static library | /usr/local/lib | regular archive file |
| libglpk.so | shared library | /usr/local/lib | symlink to shared object file |
Note: if GLPK was added as a Linux package, then the "/local" part is omitted from the paths indicated.
Caution: API users should not include GLPK headers other than glpk.h.
The path details shown assume a normal build and install. The static library is used for compile-time linking and the shared library is used for runtime linking. Depending on how GLPK was configured, both need not be present. Users sometimes encounter problems with file locations and search paths — if so, some troubleshooting hints are given below. The locations used by GLPK comply with the Linux filesystem hierarchy standard.

## Installation procedure

The following instructions refer to:
* a representative upgrade from GLPK version 4.42 to version 4.65.
Please note:
* if you are undertaking a new install, then skip any instructions relating to 4.42
* for later releases, the 4.65 should be replaced by the relevant version number.

### Prerequisites

For compilation gcc is needed. GCC is the GNU Compiler Collection. This collection includes a C language compiler. You can check the installed version with:
Using ODBC requires either the iODBC or the unixODBC package.
The default installation path is /usr/local. On Fedora derived distributions (Fedora, Red Hat, Centos, ...) /usr/local/lib is not in the library search path by default. You can add the path with:

### Obtain source

Download the GLPK 4.65 tarball to a directory within your user space (skip ahead if you already have it):
Verify the tarball:
If the key is missing in your keyring, you can install it with:
Then unpack the tarball:
Apply any subsequent patches — rarely needed as important bug fixes normally trigger a new release.

### Research

Hunt for the PDF documentation (or else change to subdirectory doc and look):
It is strongly recommended that you familiarize yourself with "Installing GLPK on Your Computer" from doc/glpk.pdf before proceeding. View it as follows:
Alternatively, similar information is available in text form:

### Configure

Next determine which configuration options you want to use. For instance, support for ODBC (Open Database Connectivity) allows MathProg to interact with relational databases and spreadsheets. List the options (the less pipe provides scrolling, hit q to quit):
Install any dependent Linux packages using your system package manager. For example, ODBC requires that the appropriate ODBC dev (developer) header files package is present.
Now configure GLPK. By default, GLPK builds both static and shared versions of the library. Common options include (you need just one of these commands):
The configuration option --enable-dl does not instruct GLPK to build a shared library, rather it tells GLPK to link dynamically with its supporting libraries.
If you need to set environment variables, do so on the configure command-line after any configuration options — use --help for more details.
Do not use paths containing whitespace characters as these are not supported by automake.

### Compile

Now compile and check GLPK. The make option --jobs=4 allows parallel processing on multi-core hardware — it should be omitted on single-core (older) machines or when encountering error messages. Depending on your CPU power, the compilation step may take from 15 seconds to several minutes.
Check the local GLPSOL version:

### Install

System installation makes GLPK generally available to all users, but does require sudo privileges. System installation is optional and can be omitted.
Uninstall GLPK 4.65 if present (steps one and three may not be necessary):
It is not strictly necessary to uninstall previous versions of GLPK, but it is good practice.
Install GLPK 4.65:
Check the expected files exist:
Check GLPSOL is generally available:
Update the runtime linker cache (may not be necessary):

### Mop-up

Finally, clean up the GLPK 4.65 source directory:
And delete the obsolete branch as required (the original GLPK 4.65 tarball will remain if present):
That's it!

## Advanced configuration options
### Source code

The source code contains more information on the build process including some useful configuration options:

### Performance tuning

When compiling GLPK with GCC on a x86 architecture a performance gain of 20 % can be gained by compiling with option -mfpmath=both. This requires SSE to be enabled. This is default for the x86-64 compiler. For the 32bit compiler SSE has to be enabled by either of -march=<cpu-type>, -msse, or -msse2.
-mfpmath=both allows both the FPU and the SSE registers to be used. See http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/i386-and-x86_002d64-Options.html
Example:
* -march=native implies that the code may not be used on different CPUs.
* -pipe reduces compile time by using pipes instead of files
* -j8 reduces compile time by parallelization, assumes 8 cores

## Troubleshooting

To hunt for key GLPK files on your system, try:
To check your current search paths, try:
Both the above calls are passive and cannot change your system.
You may need to explicitly update the runtime linker cache:

## References

* ↑ "Re: Automake's invokation of libtool doesnt handle $prefix with spaces in directory names". Free Software Foundation. Retrieved 10 May 2012.