Hardware Reference
In-Depth Information
ask your parents). Cassette tapes, or LTOs, are stream devices and by definition they are very horrible for random
access. The reason for this is that a stream device starts at the start and plays through until the end. They have no
issues with reading or writing a stream of constant data or playing back an entire album, for example. If you owned
a portable cassette-tape music player you would know firsthand that it's not an easy task to skip a track or go back
a track, unlike with a CD player where you can just jump forward or backward with ease; there is no holding down
the rewind or fast-forward button. Tapes work more efficiently with one set of data rather than smaller chunks of
data. So what has a tape drive got to do with the GCC and LTO function? For that, you need to understand how the
optimization levels are applied and when they are applied.
Without LTO, the GCC will do its best to apply the given optimizations to each object file that it finds in the
application you are building. Now you need to keep in mind that some optimization may be valid only for the GCC to
apply if it knew about another object file. Going back to the tape drive example this is as inefficient as seeking the tape
to access data randomly rather than in a stream. Sure, it works fine but it's not efficient. With LTO, the optimization
levels are applied in a very different way. LTO will try its hardest not to apply any optimization until the final linker
stage. At this point the GCC will apply the given level of optimization across the whole application instead of the
individual object files. Let's go back to the tape-drive example again. This mode of optimization is now like writing or
reading to the tape drive as a stream of data rather than random access. The GCC knows about the whole application
and as such it will be able to optimize better.
Using Symbols as Needed
The last optimization is passed to the GNU linker application, rather than to the GCC. It is called
--as-needed
.
Without this option, the
ld
linker tool runs to link your application and will link in whatever shared libraries your
application thinks it needs. A lot of the time, this will link in symbols that your application has no direct dependency
on. It's quite likely an indirect dependency or just unnecessary. This is where the
--as-needed
option comes in.
This option will do its best to only link in symbols that your application directly depends on. Simple enough, really.
This simple optimization gives you two main benefits.
•
The first benefit is that the application's size on disk is reduced. This has the added benefit for
the Raspberry Pi in fewer read/write cycles to the SD card.
--as-needed
is that the amount of shared libraries that are loaded
with the application could be decreased. Now on a system with limited resources, like the
Raspberry Pi, this is a huge benefit to your CPU and memory space, which can be lowered by
each application running.
•
The second benefit of
Two Final Advantages
Lastly, OpenELEC has a very small disk footprint weighing in at less than 130 MB. Not that it matters much:
OpenELEC can support pretty much any type of remote filesystem. Now that you know why OpenELEC is so good,
it's time to move on to the installation.
Installing OpenELEC
OpenELEC is distributed as a zipped tarball. Unlike the Fedora installer it has no pretty UI tool for installing the image to
the SD. You're going to need to use the command line to create the SD card. Fun times going back to the command line!
Because the Raspberry Pi build of OpenELEC is still under heavy development, OpenELEC is releasing frequent releases
of the build. It's a wise idea to download the latest one; this won't mean it's bug free though. Sometimes the latest build
may have a bug that affects you or you're installing OpenELEC from a Mac or Windows machine; then you're going to
want to use the prebuilt images. You can find the prebuilt images at
http://openelec.thestateofme.com/
.
