My-Tiny.Net :: Networking with Virtual Machines
GCC and Make
There are four essential ingredients in a Linux distribution: the kernel code, the C compiler, C libraries, and the the linker. Binaries from other distributions are highly likely to work when the versions of these major components are similar. distrowatch.com tracks the characteristics of about a zillion distributions.
In these modern times we usually get software from a repository, but sometimes you need to compile it for yourself.
make (or rather a Makefile) is a buildsystem: it drives the compiler and other build tools to build your code. For a multi-platform project you really want a buildsystem generator like CMake (cross-platform make), which can produce Makefiles, Ninja build files, KDEvelop or XCode projects, and Visual Studio solutions from the same starting point. GNU Autotools (automake) integrates very well with building Linux distributions. It is not a general build system generator though - it implements the GNU coding standards and nothing else, but that's good enough for the Linux kernel and nearly all of our applications.
Great Reference: https://robots.thoughtbot.com/the-magic-behind-configure-make-make-install
GNU Autotools, make, and cmake are actually insanely complicated, but they make the build process practically painless. Essentially, each application will have a "Makefile" with various targets - some common ones are make, make install, and make clean. There may be a layer "above" the makefile: ./configure is commonly used with GNU Autotools to actually generate the required Makefiles. We can add another layer to automate even more: a "app.Build" script that passes optional parameters to our buildsystem.
The basic process:
- Use mc to highlight a source code archive to look inside
- Look for configure - this one uses automake
- Look for CMakeLists.txt - this one uses Cmake
- IF you have a package that uses Automake or Cmake, THEN
- Copy and rename Template.Build to app.Build and put it into the same directory as the source code archive.
- Follow the instructions in the template to make the necessary edits and customisations
- Run
./app.Build
and if everything works, it will create two new files and install the application
- IF you do not have a package that uses Automake or Cmake, THEN
- Check the file named Makefile for options you can customise, and
- for an INSTALL target, and
- for a CLEAN target.
- Run
make
and if everything works, it will create new files in the source directories - If you can, run
make install
to move the new files from the source directories into their proper places in the filesystem - If something goes wrong, run
make clean
to remove new files from the source directories, debug, and runmake
again.
Hands On
The mytyVM-gcc.iso image is available from mytyVM Images on the menu. The install-gcc.sh script will insist you have 300mb free space, so use your Base.iso to create a new VM exactly as described in Getting Started::Creating VMs on the menu, except (a) give it 320mb RAM and use "Dynamically expanding storage" of 980mb in VirtualBox, and (b) in cfdisk allocate 950M to dev/sda1 and 30M to dev/sda2 (compiling is more about CPU than memory). The install-gcc.sh script will take care of all of the configuration steps necessary to get the VM up and running on net-b with three files of source code and a Template.Build script and /opt for you to work with.The source code in /opt is for two AsciiArt applications: the Steam Locomotive, which is supposed to help cure you of "fat fingers", and toilet which is "a supercharged figlet". The template build script is there to make it easier to manage compile options.
We want to compile sl first because it is simple and fun: all it does is run a Steam Locomotive across the screen.
To get it going:( ) (@@) ( ) (@) () @@ O @ O @ O (@@@) ( ) (@@@@) ( ) ==== ________ ___________ _D _| |_______/ \__I_I_____===__|_________| |(_)--- | H\________/ | | =|___ ___| _________________ / | | H | | | | ||_| |_|| _| \_____A | | | H |__--------------------| [___] | =| | | ________|___H__/__|_____/[][]~\_______| | -| | |/ | |-----------I_____I [][] [] D |=======|____|________________________|_ __/ =| o |=-O=====O=====O=====O \ ____Y___________|__|__________________________|_ |/-=|___|= || || || |_____/~\___/ |_D__D__D_| |_D__D__D_| \_/ \__/ \__/ \__/ \__/ \_/ \_/ \_/ \_/ \_/
- use mc to open /opt/sl-5.02.tar.gz
- use F5 to copy the sl-5.02 directory inside the archive to /tmp
- move into /tmp/sl-5.02 and use F4 to edit the Makefile
we need to add another library to the compile directive so it looks like this: ("minus little L", not one)
$(CC) $(CFLAGS) -o sl sl.c -lncurses -ltinfo
- run
make
- copy the sl executable to /usr/local/sbin and the man page sl.1 to /usr/local/man/man1
- run it with
sl
sl
"rarely shows contents of current directory",
but further investigation reveals that this will only happen when the command
is mistyped as ls
...
libcaca and toilet
The goal of the TOIlet project by caca labs is basically to create a super-enhanced FIGlet. TOIlet stands for The Other Implementation's letters, like FIGlet stands for Frank, Ian and Glen's lettersThe sl Makefile is as simple as can be. TOIlet is a different story: it requires the libcaca library, and has a lot of other dependencies because of the way it manipulates the screen. Because of these complexities the developers decided to use ./configure and the GNU Autotools build system.
With the Template.Build script there is no need to unpack the source code archives. Get /opt on both sides of mc and use [F5] to copy and rename Template.Build to
libcaca.Build
(just type the new name in the lower box),
and then set the execute permissions. Do the same again to make a new file called
toilet.Build
The libcaca library needs to be compiled and installed before toilet can be compiled. Make these changes at the top of
libcaca.Build
PRGNAM=libcaca # replace with name of the application VERSION=0.99.beta19 # replace with version of the application SRCFN=.tar # replace with source archive typeMove down to the automake Build Options to adjust the flags. This will take a little careful editing, because we need to take some out and add others in.
When command lines are long we can use \ (backslash) to break them up into multiple lines. The \ means in this case "to be continued" or "more to come". IMPORTANT: If you add a space after the \ the command WILL NOT work. Also, no comments are allowed, since this is actually a single (very long) command line, even though it looks like a list.
For libcaca we uncomment all of the options and add one line for a cleaner build; the final result should be:
# --------------------------------------------------------------------------- # automake Build Options: run # ./configure --help |less # and look for Optional Features\Optional Packages # --------------------------------------------------------------------------- CFLAGS="$SLKCFLAGS" \ CXXFLAGS="$SLKCFLAGS" \ LIBS="-ltinfo" \ ./configure \ --prefix=/usr \ --libdir=/usr/lib${LIBDIRSUFFIX} \ --sysconfdir=/etc \ --localstatedir=/var \ --mandir=/usr/man \ --docdir=/usr/doc/$PRGNAM-$VERSION \ --build=$ARCH # -----------------------------------------------------------------------Again, if there is a space after the \ the command WILL NOT work. The mc editor helps us out here - a light blue dot is a trailing space, and signals trouble!
A few lines below the compiler options there is a section for copying documentation into the package. You might be surprised at how many compilations fail because the documentation list is wrong, which is why this section is "verbose but safe". The default list could use a little adjustment, but it is really optional:
# *** you probably want to to adjust this list *** for i in AUTHORS THANKS COPYING NEWS NOTES; doFinally, go to the last section and uncomment the (two) commands to install the application to the local system, and the command to clean up the temporary copy of the application. If you don't clean up the source code and intermediate compilation files, you can see how many Makefiles the configure script created by moving into that directory after running the libcaca.Build script and running
find . -name "Makefile"
All Ready! Run
./libcaca.Build
and if everything works
it will create a .tgz archive with compiled application
(there are lots of warnings from the compiler, but it turns out they are all harmless).
You can easily move the .tgz file to your other VMs, and use mc
to copy the files inside the archive into the proper system directories.
Once you have the libcaca library compiled and installed you can compile toilet. Make these changes at the top of
toilet.Build
PRGNAM=toilet # replace with name of the application VERSION=0.3 # replace with version of the application SRCFN=.tar.gz # replace with source archive typeMove down to the automake Build Options to adjust the flags. We have to make one small adjustment after uncommenting all of the existing lines:
# --------------------------------------------------------------------------- # automake Build Options: run # ./configure --help |less # and look for Optional Features\Optional Packages # --------------------------------------------------------------------------- CFLAGS="$SLKCFLAGS" \ CXXFLAGS="$SLKCFLAGS" \ LIBS="-lz -ltinfo -lncurses" \ ./configure \ --prefix=/usr \ --libdir=/usr/lib${LIBDIRSUFFIX} \ --sysconfdir=/etc \ --localstatedir=/var \ --mandir=/usr/man \ --docdir=/usr/doc/$PRGNAM-$VERSION \ --build=$ARCH # -----------------------------------------------------------------------If you are wondering how to know if and what adjustments are necessary: these came from test runs.
This time no adjustments are necessary for the documentation, so move on down to the last section and uncomment the lines to install the application locally and clean up. These are commented out for the test runs - but we know it works now!
Run
./toilet.Build
and check that it creates the .tgz file
in /opt.
ASCII Art - Supercharged
Once you have compiled libcaca and TOIlet and installed the packages, you will see new TOIlet fonts in with the FIGlet fonts. To see the list:Unfortunately, there are a few toilet fonts that do not work with our terminal. You can use a command like this to display the font name and formatted text:ls /usr/share/figlet/ | grep .*lf
Once you get them cleaned up, run this to see a random font each timefor FN in $(ls /usr/share/figlet/ | grep .*lf); do \
echo $FN; toilet -f $FN $(date +%A); done |less
Filters and export options are what set TOIlet apart from FIGlet. UseFN=$(ls /usr/share/figlet/ | grep .*lf | shuf -n1 |cut -d '.' -f 1); \
echo $FN; toilet -f $FN $(date +%B)
toilet -F list
to see all available filters. Try it out:
TOIlet is a little bit funny with multi-line input:toilet -F gay -F border -f letter $(date +%A)
fortune |toilet -F gay -F border -f term
fortune |boxes -d columns -a hcvc |toilet --gay -f term
toilet -f term $(fortune)
does not
wrap the text properly, but
fortune |toilet -f term
does!
Just for fun, this might be worth an experiment:
toilet -f term $(fortune |fold -s -w 60)
where -s means wrap on spaces (proper wordwrap) and -w says to have only 60 characters on a line rather than the default of 80.
Bonus: libcaca Live!
The libcaca build includes the cacaserver, which reads libcaca animation files in its standard input and serves them as ANSI art on network port 51914.To use it, just set the CACA_DRIVER environment variable to raw and pipe the program's standard output to cacaserver. Clients can then connect to port 51914 using telnet or netcat to see the output.
Try it out: In one virtual terminal type
CACA_DRIVER=raw cacademo | cacaserver
and you should see initialised network, listening on port 51914
Then in another virtual terminal type
telnet localhost 51914
and let it run for a while to see the variations.
Also try this one: cacafire displays a screen with ASCII (moving) burning fire. Works the same way, with
CACA_DRIVER=raw cacafire | cacaserver