[This page needs review]
On this page:
- Download and unpack
- Configure and install dependencies
- Compile the program
- Install the program
- Cross-compile without Virtual Box
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.
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 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)
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.
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
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.
After there are no errors, you can attempt to compile the program.
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.
In a root terminal type:
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.
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:
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.
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.
Barring a proper deb source that handles all that automatically, it also seems in my experience that the old GNU autotools
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.