Next Previous Contents

4. Installing and Compiling

4.1 Anything special I have to do if I'm upgrading from E13 or previous?

Yes. Either delete the old directory and all of its data, themes, and whatnot; or rename the directory so that you may use both versions interchangeably if you absolutely must have a theme from the "old days" until it gets revised by someone.

4.2 Which order do I install/compile Enlightenment in?

4.3 How do I compile Enlightenment with GNOME?

This document does not cover this precisely, because it is not in its scope. However...

Follow the GNOME instructions as carefully as possible, but use this document's Enlightenment instructions for Imlib and the libraries it depends upon. After you have reached this point, you may complete the process in any order you wish; GNOME first, or Enlightenment first. Since they are separate packages the only things they have in common are Imlib and Imlib's dependencies and ordering after that is taken care of is immaterial. Please, do not ask the Enlightenment mailing list how to compile GNOME : use the GNOME mailing list for that.

4.4 How do I compile each package?

While I recommend looking to each package's documentation, they all tend to say the same thing. There is one thing you should do however, before starting: make sure that your libraries will be installed in a place your system recognizes as a place to store libraries. This involves making sure that where they get installed is actually listed in your human-readable /etc/ld.so.conf and ldconfig run on them afterwards to ensure it takes.

Normally, the common procedure to use for each package is:

Provisio to the rule:

4.5 Make went okay, but make install didn't. How do I fix it?

You probably received an error that looked like this:
/usr/bin/install: /usr/local/bin/filename No such file or directory

Delete the offending file, and try again. You might want to look inside the Makefile to see what else is installed, and delete them too. Install has trouble overwriting things when you delete the Enlightenment tree from an upgrade and leave the symbolic links in the path (usually /usr/local/bin). Either refrain from the habit when upgrading, or delete them too.

4.6 Why do I get compilation errors when I upgraded Enlightenment?

There are plenty of good reasons why and some bad ones. But here are some possibilities:

4.7 Why won't Imlib accept Libpng when it is installed?

or

4.8 Why are my PNG graphics so messed up sometimes?

You probably have the wrong version. If you downloaded v. 1.0.2 instead, it has bugs throughout it that cause any transformed (ie, 90 degree turns) graphics to be mangled. If you have a lower version that v. 1.0.1, then you will get a cannot find png_set_valid error from Imlib's configure script. In either case, call it upgrading and scarf v. 1.0.1 from the Grab Map.

4.9 Why do I have libpng.so.2.1.0 when I installed Libpng v. 1.0.1?

The author made a break with compatibility with earlier versions and this results in naming the resultant shared library with a different major version number (ie, n.x.x, where n is greater). The digits have been kept as a historical reference so that other systems can determine which one is "newer." Don't worry, you have installed the correct one and Imlib will like it. Yes, the older versions are named as you expect them as so.1.x.x, but you do not want them as they are incompatible.

4.10 Why do I have libtff.so.2.0.0 when I installed Freetype v. 1.1.0?

The author made a break with compatibility with earlier versions and this results in naming the resultant shared library with a different major version number (ie, n.x.x, where n is greater). The digits have been kept as a historical reference so that other systems can determine which one is "newer." Don't worry, you have installed the correct one and Enlightenment will like it. Yes, the older versions are named as you expect them as .so.1.x.x, but you do not want them as they are incompatible.

4.11 How did you compile Libgr? Mine won't work.

Looks pretty messy, huh? Luckily this is on most people's systems already if they run Linux as it is a 'standard" graphics library. If not, don't worry as this is an old requirement, not a current one. It was initially used because it had a great deal of the graphic library requirements, thereby fulfilling many dependencies. Unfortunately, however, it was badly maintained and eventually became outdated for several of the libraries in question. As such, it is no longer used, although whatever it provides if you already have it will not be harmful to your system as far as Enlightenment and its cohorts are concerned. If you do have the Libgr package, you will still have to grab the dependencies from the Grab Map, regardless of whether the libraries reside on your hard drive as many are too old to be useful. Only install this package if your own distribution requires this as a system dependency, and only first in that case.

This is especially true for Libpng as this is the most used library in themes, including the default theme, and is incompatible in the version Libgr provides.

4.12 Why can't I get ConfigEdit to compile?

Gtk-Perl requires a newer version of Perl itself than you might have. Check to make sure that you have an up-to-date Perl installed correctly on your system if this is failing to compile at a higher level.

Another possibility is that you have an incompatible version of Gtk. Gtk-Perl 3.0.0 has been updated to be compatible with Gtk-1.1.x. The older version, v 2.4.0, has not; if you have this version already installed on your system, it will not work correctly, and the only workaround then would be to downgrade Gtk, or upgrade your Gtk-Perl module. Unfortunately for some of you, 3.0.0 is only currently available in source form.

4.13 Why aren't the macros for Automake and/or Libtool found?

Unfortunately, the macro libraries that search for these on your system by using Libtool and Automake are broken in the respect that they like being in the same tree. This means that if you installed one of the compiler tools under /usr and one under /usr/local, they won't be able to find each other.

This usually happens because you've personally installed one or more, and there were pre-existing complements already on your system under /usr. There are few ways to fix this problem:

If using the second method, do not worry about any errors that occur, as this just means that the directory being linked to doesn't want it because it already exists, and are spurious in this case.

4.14 I'm still having trouble. What can I do to pinpoint it?

There are a number of ways, depending on what stage of completion you managed to get to, you can see what the binaries are linking succesfully to and what they aren't by typing ldd filename. Note that this only works on executables and shared (*.so.*) libraries.

If you have gotten as far as compiling Enlightenment itself, typing ldd /usr/local/bin/enlightenment should get similar output results as below. Please note the version numbers of the *.so.* libraries, and that they are all there, and linked to Enlightenment. No, the last number in brackets is not indicative of anything useful for our purposes, but merely points to an address.

If you have not gotten as far as being able to compile Enlightenment itself, then you must weed out what is negatively influencing your Imlib compilation. This requires a bit more dedication that typing in a single command and getting valid information from it. Adjust the directories for your system and type (or paste) the following and remember the "two thumbs up" rule:

Last, but certainly not least, check to see whether you have two versions of your library on the same filesystem. If you have an up-to-date locate that actually matches what's on your drives, type locate libpng.so and check to see whether Libpng has two separate versions; normally if this is the case, you will see one habitating /usr/lib and the other /usr/local/lib. Simply remove the unwanted party, and follow the instructions on re-<tt>Make</tt>ing. Please note that you might potentially "break" applications that are precompiled for the soon-to-be-departed library. Recompile them if this is the case, and you nee said application, but this is generally a rare occurence with an outdated library.

However, it would not hurt to see where you might run into problems ahead of time. To check, type:

ldd *|grep -e "/usr/lib/libpng" -e ":" -|less

to see whether, for instance, any given programme in that directory cannot live without a version of Libpng in /usr/lib. All programmes will be listed with a colon after themselves, and any possible library conflicts will be listed after each. To add more library checks at once, just include another `-e "/path/libwhatever"' next to the others on the command line. Good places to type this command in would be:

/usr/bin, /usr/local/bin, /usr/lib, and /usr/local/lib.

This will ensure that even other libraries will not depend on this old cruft you throw out, and leave you stranded later. Make a list, and shop for the programmes you still want, and get new, shiny versions of them to match your new, shiny versions of the graphic libraries you just replaced them with.

Next Previous Contents