Tag Archives: Make

LFS 6.8 (Part 10): The Second Part of the Rest of the Temporary Toolchain

The LFS temporary toolchain is going to take a while to cover completely, so I’m breaking it up into several parts for readability.

I’m about halfway through building the LFS temporary toolchain, and encountering mostly smooth sailing.

Grep

According to Wikipedia, “The name [Grep] comes from the ed command g/re/p (global / regular expression / print).” What Grep does is search files for the patterns you specify.

Grep installed to /tools (in the temporary toolchain, /mnt/lfs/tools).

Grep was supposed to build in 5 minutes, but with the test suites took a total of 19 minutes.

Gzip

Gzip is an older and only fairly efficient compression tool, but it works well enough that it is still a near-universal compression format.

Gzip installed to /tools (in the temporary toolchain, /mnt/lfs/tools).

I calculated Gzip to build in less than 5 minutes, but took 8 minutes. Those test suites! Well, at least I’m getting practice in what to look for.

M4

M4 is (as the LFS book puts it) a macro processor typically used to pre-process source code for a compiler. What does it do that’s so different from any other scripting/macro language? I don’t know, but it probably is very well suited to pre-processing source code for compilers, since that’s what its used for 😛 .

M4 installed to /tools (in the temporary toolchain, /mnt/lfs/tools).

M4 should have taken 10 minutes to build, but test suites inflated that number to 29 minutes.

Make

Ah, Make is our friend! Make automates the compiling of programs by reading that Makefile you keep seeing in the source directory and compiling the program accordingly. I can’t imagine what it would be like doing all of the steps by hand. The LFS book would be huge!

Anyway, Make is installed to /tools (in the temporary toolchain, /mnt/lfs/tools).

For all its versatility, Make was only supposed to need 5 minutes to build, but with its test suite, 7 minutes.

Patch

Patch modifies source code by applying the changes specified in a patch file. This makes it easy to apply small fixes with accuracy without having to wait for the developers to update the whole program.

Patch is installed to /tools (in the temporary toolchain, /mnt/lfs/tools).

Patch was projected for a less-than 5 minute build, and finished in a satisfying 4 minutes. Including the test suite!

The test suite threw up two errors, though. One error seemed to be dependent on the ed text editor, and the LFS live CD apparently didn’t have it; however, it shouldn’t have run anyway, so no biggie. The other error I couldn’t even track down, and seems to be a failure of cat or something. Since I couldn’t find a way to fix it (or even figure out what it was), I decided to forge ahead regardless.

Perl

Perl is a general-purpose scripting language, often represented with a camel mascot. There is much that can be said about Perl, but you have Google for that 🙂 .

First I had to apply a patch “to adapt some hard-wired paths to the C library” and run Perl’s configure script to build a minimal Perl for testing purposes (which is all it will be used for in the temporary toolchain). When I installed Perl, I only needed the utilities and one library, so it built in a lot less time than it will later. Perl installed to /tools (in the temporary toolchain, /mnt/lfs/tools).

I did skip the test suite, since the LFS book informed me that all of the rest of Perl would be built as well for the test; because Perl was only partially built, “installing” the temporary toolchain Perl was really just copying directories. Again, because this is a minimal version of Perl for the toolchain, it should only take 39 minutes to build, but it took 2 hours 9 minutes. I have no idea why so slow; I guess Pressie is getting tired.

Sed

Sed is a commonly used *nix tool for editing text, and is especially handy for shell scripts.

Installing Sed was straightforward, and Sed was installed to /tools (in the temporary toolchain, /mnt/lfs/tools).

5 minutes is all Sed should have taken to install, but the optional test suite inflated that to a full 7 minutes.

Tar

Tar stands for “tape archiver”, so you can guess how far back its roots go. Tar made backup to tapes easy by concatenating files into a single .tar file. This made backups to tape much easier, as the tape didn’t have to rewind and fast forward back and forth between a single file and the master file table.

Anyway, Tar was installed to /tools (in the temporary toolchain, /mnt/lfs/tools).

Tar should have taken 15 minutes to build, but with the optional test suite, Tar took a full 57 minutes to build (all okay, though).

Texinfo

Texinfo is a suite of utilities for manipulating info pages (a longer, more detailed version of the man pages).

Texinfo was installed to /tools (in the temporary toolchain, /mnt/lfs/tools).

Simple to build, Texinfo was scheduled for a 10 minute build, but took 12 minutes with the optional test suite.

Xz

Xz is an up-and-coming compression format that hopes to mostly replace less efficient formats like Gzip and Bzip2. It is great for source code, as Xz compresses text even better than either Gzip or Bzip2.

Xz installed to /tools (in the temporary toolchain, /mnt/lfs/tools).

15 minutes expected, 17 minutes taken (test suite included).

Now What?

All the packages for the temporary toolchain are now installed to /tools (in the temporary toolchain, /mnt/lfs/tools), and I am ready for the final steps in preparing the temporary toolchain for action!

Compiling Emacs 23.2 From Source (Part 1)

As part of my goal to learn Linux internals from LFS, I’ve done some reading and experimentation with compiling software. Learning to compile software from source is widely considered an essential *nix skill, as many patches, tweaks, and settings can only be added or modified at compile-time. Also, building a LFS system requires compiling everything from source yourself, so I’ve got to learn some time.

Emacs, a text editor (in)famous for its extensibility, is the first software package I’ll practice compiling from source. Why start with Emacs? Emacs can be bent into doing pretty much anything you’d expect from a full-featured OS — e-mail, web browsing, music playback, Tetris, psychiatry… even text editing! — so there are obviously plenty of opportunities to learn how to compile special abilities into Emacs. Also, along with vi/vim, Emacs is a standard text editor for *nix systems, so I need to become at least somewhat proficient with it. Even the LFS essential prereading guide recommends Emacs as a starting point for package-building practice, so it’s probably a pretty good place to start… right?

So I began my dance with Emacs by grabbing the source for Emacs 23.2 from the gnu.org FTP server (~45MB) and extracting the .tar.gz to my Desktop folder (this is a good time to read any README files).

Next, I ran ./configure, a shell script for Emacs that generates makefiles (detailed instructions for compiling from source) based on a computer’s hardware/software configuration (and any special parameters you give it), and I hit my first snag:

Running ./configure

Running ./configure

As you can see, ./configure ran, but complained that several libraries were missing (image libraries in this case). I reran ./configure with the --with-xpm=no --with-jpeg=no --with-png=no --with-gif=no --with-tiff=no options that the first run said were missing, to see if I could bypass the error and get Emacs running at all.

Running A Slightly Different ./configure

Running A Slightly Different ./configure

Success! Once the ./configure script ran successfully (i.e., created valid Makefiles for compilation), I ran make, the slightly automagical compile-from-source tool. After about one or two minutes, make finished with no errors.

NOTE: make compiles the source code into the specified directory (by default the same directory as the source code), which makes it ideal for testing (run make clean to “reset” and try again if something breaks). make install, however, installs it to the normal program installation directories, so mistakes have more dire consequences for your time, as you have to hunt down many more loose ends.

This Means It's Finished, Right?

This Means It's Finished, Right?

I opened up Dolphin and browsed to the ~/Desktop/emacs-23.2/src/ folder, and ran the freshly-compiledd emacs:

Very... 1990s

Very... 1990s

It looked pretty shabby, but I suspect Emacs would be perfectly serviceable in this state. Compared to the Ubuntu package, you can see that there are definitely a few things missing from my homebrew build, including color image support and (semi-)native theming.

Very... 2000s

Very... 2000s

It seems I have a way to go before I get something as polished as Ubuntu’s tweaked-out version. However, I did manage to compile a program from source for the first time! Next time, I’ll try to get those image libraries working, along with a few other tricks and tweaks. Until next time, happy hacking!