[This page needs review]

          See also Compiling and installing a new kernel

---

On this page:

• Introduction
• Preconfiguration
• Download and unpack
• Configure and install dependencies
• Compile the program
• Install the program
• Cross-compile without Virtual Box

---

Introduction

Compiling transforms source code written in a programming language into a binary form that creates an executable program.

• Before compiling software yourself, you might want to search for already compiled package via Synaptic. This is usually easier and most good software is available this way.
• If the software is not available in the repos, check whether it is in Debian Testing or even Experimental. If it is there, post a request on the MX Forum for it to be backported.

Preconfiguration

The trickiest part of compiling is setting up a “build environment” for the software you want to compile. This involves installing “dev” packages which contain header files for the various software libraries a package requires. If you don’t have a required “dev” package, the “configure” portion of the compile will either fail, or it will configure the package without certain features which depend on those libraries. Figuring out which package to install to satisfy those dependencies can be tricky, but if you install the X, Qt, and Xfce development libraries, you will cover the needs of most simple programs.

If you are compiling drivers, you will also need the kernel headers. Finally, you will also need checkinstall for creating .deb packages.

Type in a root terminal:

apt-get install xorg-dev libqt4-dev checkinstall

Kernel headers should be already installed, but if not type in a root terminal:

apt-get install linux-headers-$(uname -r)

Download and unpack

Download the source code from the project’s website. Many open source projects are hosted on Sourceforge, where the MX tools are also listed (https://github.com/mx-linux/).

You want to download the source code. Since we are compiling from source we do not need any of the *.deb, *.rpm, *.exe, or other ‘precompiled binaries’ available at the project website. The file usually comes in a *.tar.gz, *.tar.bz2, or *.zip format. After you download the file you need it to extract it by right-clicking it and selecting “Extract here” or in a terminal by following these directions. 

Sometimes you may want the very latest version of the program that hasn’t been released yet. Developers keep the code in repositories, which allow them to make collaborative changes to the project and easily make backups. They may suggest downloading the repository version from GitHub or give a line of code starting with cvs or svn. If you would like the development version, paste that line of code into your terminal to get that version (you would need to have the corresponding software installed and configured on your computer)

Configure and install dependencies

Navigate in your file manager or in a terminal to where the package folder is located. Typically, there is a file called README and INSTALL or similar included. Take a brief look at these files by clicking to bring them up in your text editor, or in a terminal with the less command: less README

Follow the instructions in these files. More often than not, they suggest the typical Unix ./configure, make, make install series of steps. The rest of this article assumes this is the case. If you see a file in the unpacked directory called CMakeLists.txt, you will want to follow the configure/build instructions for Cmake.

./configure 

or, better:

./configure --prefix=/usr 

You figure out what else you may need in the ./configure step. If you get an error that says, effectively, “you don’t have this program,” you need to do some fix’in. Usually it means looking for a similarly named package or a package named libpackagename or packagename-dev. “-dev” for development. If you already have it installed and the “-dev” package installed, do

./configure --help

and you can sometimes see an option to pass to the ./configure command to tell it where to look for programs. You can find the place where the files are installed with:

dpkg --listfiles packagename

or in the “Installed Files” tab of Synaptic.

Repeat ./configure until there are no errors.

Compile the program

After there are no errors, you can attempt to compile the program.

make

If all goes well, gcc will write messages all over your screen for quite a while as the magic of compilation takes place. When it has finished, check to make sure it did not end in any errors. It may be possible to continue with errors, or you may need to go back and fix them.

Install the program

In a root terminal type:

checkinstall

Follow the prompts and enter the desired info.  NOTE: the traditional command here (which will also work) is make install

Checkinstall creates a .deb package from the compiled program and installs it. You can manage the package afterwards with the usual tools: dpkg, apt-get, Synaptic, etc.. This way is easier to remove the package that you installed. After you are finished, you may want to move the .deb package for safe-keeping, reinstallation later, or installation on another machine. You can the delete the source code directory when finished.

Cross-compile without Virtual Box

references:
building-arm-debs-with-pbuilder
stevo’s MX Forum thread
zip of the ~/.pbuilderrc file

The packages we need to install for Debian builds are pbuilder qemubuilder debian-archive-keyring qemu-user-static. Then create pbuilder machines for your desired OS, release, and architecture–example:

 OS=debian DIST=stretch ARCH=amd64 pbuilder --create 

This should work for simple packages, like the Qt 5 MX applications, that don’t need any build-deps that aren’t in the standard Debian repos. Then, from the root of your Debianized source folder, you can run these commands (in separate terminals if you want to speed things up, I’m just going to list Stretch builds as an example, and what arch you use with the -sa and -B options doesn’t matter)

OS=debian DIST=stretch ARCH=amd64 pdebuild –debbuildopts -sa
OS=debian DIST=stretch ARCH=amd64 pdebuild –debbuildopts -B

Once done, the source, package, and other files will be found in appropriate folders in /var/cache/pbuilder, and you can sign them for the repo with:

debsign <name_of_,changes_file>

I have tested building mx-viewer for the armhf architecture (Pi), and it also worked. This also worked for a pbuilder rebuild from jessie-backports and the mozjs-38 packages that refused to build successfully on MX. According to the guide, it may be possible to “hook” the MX repo to these Debian environments to make them complete MX build environments, but I haven’t tested that yet. The builds will take longer than in a straight virtual machine, but that is offset by the fact that you can do multiple architectures and DISTs simultaneously.

 

 

---

v. 20150815

Comments

Important comment from Stevo on v. 20150815

I think it should stress that creating a proper deb package is by far the preferable option, either from upstream source, Ubuntu, or a PPA.

https://wiki.debian.org/SimpleBackportCreation

https://wiki.debian.org/CreatePackageFromPPA

Barring a proper deb source that handles all that automatically, it also seems in my experience that the old GNU autotools

./configure
make
su -c ‘make install’

procedure is used by a definite minority of packages today, what with the QT qmake and cmake etc. getting very popular. For example, none of the MX packages will build with that procedure, so the beginner should definitely read the documentation in the source as to the build procedure.