Building Linux Audio Applications 101: A User's Guide, Part 2
In this article I finish the process we started in the last episode. Read on for the thrilling denouement.
After all the preparation described in the first part of this article the build process itself is rather anticlimactic. Building from sources with the GNU autotools is this easy :
./configure --help ./configure --with-optionYY=yes --with-optionZZ=no make sudo make install
The make command starts the build process. Its actions depend upon the directives found in a very important component called a makefile that typically includes a variety of commands to summon the required dependencies, compiles the individual object files (more about those files in a moment), links the objects into a single executable (a.k.a. the binary), and installs the completed program.
However, the source code must be configured before running the make utility. The following commands will display the configuration options for some of the more popular build managers :
./configure --help (with the autotools system) ./waf configure --help scons -h (local options) scons -H (global options)
Check for the available configuration options before proceeding to the make stage. The configuration stage will determine whether your environment includes the correct tools for constructing the software. It will also let you know about missing dependencies, version mismatches, special enhancements, and any other features or problems that will affect the build process.
A few words more regarding configuration options. Some may be enabled by default, while others must be manually added to the configuration stage. For example the following options declare the installation's target directory tree and adds support for the LAME MP3 encoder :
./configure --prefix=/usr/local --with-lame
When the build process has reached the linking stage the LAME library will be added to the library dependencies. When you run the installation procedure the program and its needed parts will be installed to the /usr/local directory hierarchy. Thus, the executable binary will be found at /usr/local/bin/progname, its headers will be in /usr/local/include/progname (or possibly just /usr/local/include), its examples and templates will be in /usr/local/share/progname, and so forth.
With Scons, once you've determined which options you want you simply add them to the scons build command in this manner :
scons OptionA=1 OptionB=0
where 1 indicates that the option is to be used, 0 leaves it unused.
The waf system incorporates aspects of the autotools process :
./waf configure --help ./waf configure --prefix=/usr ./waf build
Typically you can run waf with no options and it will return a list of available options and targets.
Assuming a best case, once the build process begins it will automatically run until it either completes the build or hits an unrecoverable error. Fortunately all build systems report critical errors in such a way that should assist in resolving the problems. The configuration stage can miss dependency details that won't appear until the compiler reaches the linking stage, the final step in the build process. You may find that a component is still missing or that a different version is needed, in which case you'll need to retrieve the required part or build it yourself. When you return to your original process it should restart the build from the point where the error occurred.
Installation And Uninstalling
Installing your newly built software is easy, but it does require root (superuser) privileges. It also requires a specified installation directory. Typically you'll install a new program or utility in either the /usr or /usr/local hierarchy. The target directory can be indicated with the --prefix option for an autotools-based build or added to the build utility's configuration file (e.g. the Sconstruct file for scons). Such an option allows installation in any indicated directory, such as /opt or the user's $HOME directory. However, if you intend to run the program from anywhere within the system you must ensure that it is visible to the system by adding its path to the PATH statement, e.g. :
That command adds two new paths to the existing system path ($PATH). Now you can invoke programs in those paths from anywhere else in your system.
On some systems it is relatively safe to install new versions of software over the distribution's installed versions. However, care must be taken to indicate the correct installation path, else a double installation may occur. This situation is not going to blow up your system, but it will surely confuse it until you either remove the original files or re-install the new ones (after uninstalling them from their incorrect targets). It is also imperative that you know exactly what you're doing before upgrading or downgrading system components, especially components of the audio infrastructure. Applications may be version-dependent, so move rather than destroy the original components. You may yet need them to restore a borked system.
Look out for stale configuration files for applications, especially in your $HOME directory. It's best to remove them or copy them to a temporary directory, the application should replace them after a first run.
A final consideration for system software. Most installers will update the system library cache by invoking ldconfig at the end of the installation, though you may want to run it manually if you're unsure about the update. Also, make sure your installation target hierarchy (set with the --prefix configuration option) is included in /etc/ld.so.conf. It won't do much good to install something in /usr/local/bin if the /usr/local hierarchy is not in the system's library search path.
Okay, you built the program without troubles, you installed it successfully, you've run it, and it just isn't what you were looking for. You want the disk space back, so it's time to uninstall, an action that might be a simple one-line command or a nightmare of hunting for the installed parts and removing them by hand, one by one. Most build systems include mechanisms for uninstalling a program, such as the following commands for three popular systems :
sudo make uninstall sudo scons -c install sudo ./waf uninstall
Your package manager can be used to remove components previously installed by your distribution. However, it is important to note whether the removal is normal or complete. A complete removal will uninstall all files associated with the package, including configuration and preference files. Complete removal is advised when you intend to replace system components such as ALSA or JACK, but the normal removal procedure should suffice for user-level applications.
Outro, Part 2
I hope you've enjoyed this little technical tour, even if you're an old hand at rolling your own apps. As I said in the beginning of the tour, it's not rocket science, anyone can learn how to do it. Consider the instructions, proceed with deliberation, and trust your intelligence. I'm not a trained computer engineer, I have no background in computer science (or any other science), I don't even have a college degree, but I routinely compile, install, and configure the audio software I use here every day at Studio Dave. I get the best fit for my hardware, along with the satisfaction of knowing exactly what support has been built into my system. Truly, if a self-taught 59-year old musician can do it, you can too.
Similis sum folio de quo ludunt venti.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide