Common problems when installing tar-ball source packages


I do not use any standard Linux distribution. So I have to compile most of the system components by my own. Sometimes this is a bit tricky, because some packages fail to compile due to configuration errors.

Recently I upgraded my system to glibc-2.3.2 using gcc-3.2.2. It works fine, but some packages need to be installed in a non-standard way. Here you can find some hints, if you get stuck in compiling these packages. I do *not* guarantee that these hints work for you, but on my system I got most of the packages up-and-running.

General hints

If you get stuck, read the manual, read the FAQ!
If this still doesn't work, use the Internet!
First you should look out for updates. If there is no update available, often other people had the same problem before, so there is a slight chance that others may have patched the program and published the patch on the Internet. You simply have to search at common places: freshmeat, google, etc.
If you cannot find a new version nor any patches, don't give up. There is still a chance that you can get things working. But it might be some work for you now. And there is *no* guarantee that you will succeed, so possibly you have invested time for nothing.
Often problems are related to other problems which are already solved. Read mailing lists, if they are available. Use a search engine (eg. google) and type in some keywords to find places where to start...
I would suggest to wait some days and repeat the beforehand process again before you consider to contact any experts. If the problem still remains, you should contact the author or other experts which are related to your problem. But bear in mind: Experts have a lot of work and generally they don't want to be disturbed with trivial problems (especially when they are not getting paid for solving them)! So it is a good idea, if you prove in some way, that your problem is not trivial.

Problems related to glibc-2.3.x

A common problem related to glibc-3.2.x is that errno is not available as int anymore. It is now only accessible as a macro. Therefore most programs which are relying on the assumption, that errno is exported as int, won't compile anymore. If you are following the discussions related to wine (see www.winehq.org) in the beginning of 2003, you get some idea of the problem...
Also mysql (up to mysql-3.23.55) could be affected by this problem, if you want to compile the sources in the standard way. A simple workaround is to modify include/global.h in your mysql source directory to contain #define HAVE_ERRNO_AS_DEFINE .

Problems related to gcc-3.x.y

There are two common problems in relation to the C++ programming language.

Source code incompatibilities

In gcc-3.x the standard template library has been implemented regarding to the ISO-standard. Some older programs are not complying with the ISO-standard, so they won't compile anymore. If your program won't compile due to these incompatibilities, try a newer version. If source code incompatibilities are not already fixed in newer versions or patches, you can change the source code by yourself... Sometimes only slight changes are necessary:
As an easy example, you can get the debugger ddd-3.3.1 compiled by editing ddd/config.h in the source directory of ddd-3.3.1: #define HAVE_IOSTATE 1 and #define HAVE_STREAMPOS 1 will do the work!

Source code incompatibilities are mainly a problem in relation with gcc-2.x and gcc-3.x.
Another solution to your problem is simply to ignore it: Create an environment with older versions of glibc and gcc...

Binary incompatibilities

Binary incompatibilities are a problem in conjunction with gcc versions before 3.2 and the new versions of gcc. Here the solution is obvious: Replace the affected underlying packages and libraries with recompiled versions!

Problems due to linking libraries

Sometimes you get linking errors due to missing or incorrect libraries (wrong library version or a library that was created by an incompatible compiler). In such cases try to install recompiled versions of the underlying libraries and recompile your package.
In rare cases linking errors even result on mixed code generation between C and C++ code, where linking against the libstd++ library has been forgotten. In such a case you can take a look at the appropriate makefile and add -lstdc++ at the end of the line that starts with LIBS.
As an example of the latter case, I got linking errors complaining about new/delete in the package smpeg-0.4.4 due to mixed C and C++ code. I simply added -lstdc++ at the LIBS-line in the makefile and recompiled the package.

Hint

Whenever I compile a new library version and I need the old library because of dependencies to other packages, I move the shared library to a special directory and remove the rest. I named the special directory lib-deprecated. This name needs to be added as an entry to /etc/ld.so.conf. Do not forget to call ldconfig, so that the library will be found by the dynamic linker!
The advantage of the foregoing procedure is that I can search for packages that use deprecated libraries by doing a ldd on each binary which resides on my system. The resulting list can be grepped for the keyword deprecated. This can be done by a simple shell script!


to be continued...
Thorsten Reinecke, 2003-03-16; last change 2003-04-11