I am following a course Data Structures as part of the pre-master
programme at university. During this course, there are homework
assignments that should preferably done in LaTeX. Now, making
drawings in LaTeX can be a pain in the a$$.

One of my instructors recommended using the program ipe to
do this. As this program is not available as a package in the
Mandriva repository, I have to compile it from source.

The instructions on the website assume a debian based system,
but Mandriva is a redhat bases system. So, the first step,
dependencies. As the package naming scheme on rpm based
systems differs from deb based systems, this is the first thing
to look at.

The install.txt file mentions:

    sudo apt-get install zlib1g-dev libqt4-dev
    sudo apt-get install libfreetype6-dev libcairo2-dev
    sudo apt-get install liblua5.1-0-dev gsfonts

First of all, I don’t like to use sudo, I prefer to use su. As I like to
have a different password for root stuff then for user stuff.
So, I will execute the commands from a root shell.

    urpmi zlib1-devel libqt4-devel
    urpmi libfreetype6-devel libcairo-devel
    urpmi liblua-devel

The different naming scheme includes the prefix -devel in stead of -dev,
which isn’t that hard. But for example, the debian scheme has a libcairo2
while the redhat equivalence is libcairo. The gsfonts package… well…
it’s a package that contains certain ‘type 1’ fonts.  As there is no package
with simular names available, this might get a little more tricky to find the
corresponding package. But the readme file gives a list of file names that
should be included,  but unfortunately, these file names give no results either.

Another line in the readme file gives me a clue:

   Identical fonts may also be in subdirectories of
   “/usr/share/texmf/fonts/type1/urw” or
   “/usr/share/texmf-texlive/fonts/type1/urw

There exists a package named ‘texlive-texmf-fonts’ so, I guess,
that will be the one I need. So, this will be

    urpmi texlive-texmf-fonts

So far for the dependencies. Let’s compile the program!
Really? No!

The first problem to appear is, a program named, moc-qt4 is not
found. Well… the solution to this problem is to make a symlink
to /usr/lib/qt4/bin/moc.

Well… trying again…. still no success… it’s raining messages
about undefined references. Which means, the Makefile doesn’t break
on errors correctly, as it should.

Settings the terminal to unlimited scrollback reveals the following error,
somewhere at top

Package lua5.1 was not found in the pkg-config search path.
Perhaps you should add the directory containing `lua5.1.pc’
to the PKG_CONFIG_PATH environment variable
No package ‘lua5.1’ found

Weird…. I *did* install the lua devel package, right? Perhaps it’s
the wrong version? Well… lua -v says it’s 5.1.4, so that should be
right. Different makes in the pkg_config databases…. that’s new
for me, as pkg_config should exists undependable from the packaging
system, as it will also include software compiled from source.

Well… how to solve this. Open the config.mak file and replace
lua5.1 with lua. Now, finally, the program seems to compile.

make install seems to work fine as well,

…but the next step from the readme file:

sudo cp ../fontmaps/gsfonts-fontmap.xml
/usr/local/share/ipe/7.x.y/fontmap.xml
sudo ldconfig

What??? having to copy a file after running make install???
Isn’t make install supposed to install all files???

Also, it seems that make clean is broken

All I can say, this is a bad makefile. Making certain assumptions
about the target system, which is basically a bad idea.

Seeing how much trouble it is to get it to work, this is bad,
not just for this specific program, but for open source software
in general, as this is what gives open source software the reputation
of being difficult to install.

autoconf/automake is used to compile many open source software
programs. Yes, it has also it’s disadvantages, like being slow,
and one sees it checking for irrelevant things, like checking for
a fortran compiler when we’re going to compile a C program, but,
nevertheless, autoconf/automake would have prevented the kind
of problems which I experienced when trying to compile the
program, (except the names of the packages, of course)

ANd I’ve noticed, ‘make clean’ is also broken.

Well… the software is installed, right? Let’s run it….
Uhm… NO!

ipe: error while loading shared libraries: libipeqtcanvas.so.7.0.14: cannot open shared object file: No such file or directory

great….. f*cking great… Did I mention I have to run ldconfig MANUALLY?
right…. adding the /usr/local/lib to the ld configuration. Now it *finally* starts.

Now, this program better be f*cking great since I’ve spend a lot of time
to get it working.

« »