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.
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,
- is there a newer version available?
- are there patches available?
- is the problem discussed anywhere?
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
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!
- add using namespace std; at
the end of #include sections
- try to include modified library versions or header files
- changing types (int <--> streampos)
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 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
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.
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...
2003-03-16; last change 2003-04-11