Glibc2 on Linux: Known problems
Note that this documentation is historic. It may no longer be very relevant. There will be no updates or further releases.
Introduction
From the first publication of this document, many people have dropped me a note telling me whether they liked it (I love such email!) or telling me about problems they found. Some problems could easily be solved, some others remain a mystery to me. This page enumerates the most important and interesting ones, together with some suggestions from me. This does not mean, though, that I am not interested in reports describing these problems, and I will do my best to help you if you contact me.
Just to assure you: I have had several reports of people who installed everything as described without encountering any of these problems. If you consider the fact that most people only email if they do encounter problems, things are not as bad as they may seem.
- I tried to use Some newer version of a package, and something did not work out! What to do?
I try to keep these pages as up-to-date as possible, but unfortunately a new version of a package may take some while to appear on these pages. Remember that I have to test things a bit before I can write these docs; gcc-2.8.1, for example, broke several things.
Also, I will not document alpha/beta software, with the single exception of glibc itself. So if you want to compile anything that did not appear (yet) in the tsx-11. GCC base directory or the prep.ai.mit.edu gnu base directory, chances are you have pre-release stuff and you are on your own.
- I want to use EGCS; what to do?
EGCS (a gcc release by Cygnus) is a separate branch in the GCC development tree. I have heard both good and bad stories about it, but the last I heard about it is that it still is beta (and may well stay that way by definition). I have had some reports that you can use it instead of vanilla gcc, as long as you make sure you have the latest updates.
Perhaps, somewhere in the future, I may try EGCS myself. Until then, you are on your own...
- I want to create a native glibc-2 gcc, but I get a signal-11 error. Help!
This is a reproducable error, but I do not know its cause. The exact error message is as follows:
./xgcc -B./ -DIN_GCC -s -O3 -fomit-frame-pointer -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -I./include -DNO_MEM -DNO_LONG_DOUBLE_IO -O0 -I. -c ./enquire.c
xgcc: Internal compiler error: program cpp got fatal signal 11
This is during the creation of the second-stage compiler.
I have had a report that compiling enquire.c without optimizations may solve thtis problem. I have not yet found the time to try it myself.
- Why do you use 486-optimisations, but refer to compile-times as found on a Pentium?
At last a simple question with a simple answer. I owned a 486 myself until recently, but I had temporary used a Pentium owned by someone else. I have written this document on the Pentium, but because I knew I would move the harddisk from the Pentium back to my own 486, I optimized everything for the 486 (even though I compiled it on the Pentium).
By now, I have upgraded to a Pentium; but all references will still be to a 486.
- Netscape 4.04 (or another program) reports it can not resolve
__builtin_new, or a similar symbol.
This is a problem with libc-5. It should be solved as of version 5.4.44.
It has to do with compiling libgcc.a into the shared library or to do that not. To solve this, select Old GCC instead of New GCC when configuring libc-5.
- Help me, I am confused! Where should I install package X? Should I use
/usr/i486-linux-libc6/bin or /usr/bin?
Remember that when you compile a packet using the cross-compiler (ie. you generate glibc-linked files), all include files and libraries should go into /usr/i486-linux-libc6/..., but the binaries should go into /usr/bin (or /sbin, or /bin, or /usr/local/bin, or...). The one exception is compiler-related tools which are different for glibc and libc5 (ie. if you need separate versions for processing each kind of file).
It may help to install the package first under /tmp, so you can see where it wants to put its stuff.
- Gcc 2.8.1 seems to crash! Can't I even trust my compiler anymore?
Unfortunately, gcc 2.8.1 seems to be a bit more error-prone than version 2.7.2.3. I expect that is a temporary problem, which will be corrected in later versions. One good suggestions: if something does not compile, try to use no optimizations (remove any -O flags). This is often enough for a succesful compilation. And if you did not remove your old version stuff, you can always try make CC='gcc -V 2.7.2.3'...
- When compiling X-programs, I get a
gcc: cannot specify -o with -c and multiple compilations errors.
It seems that the cpp coming with gcc-2.8.1 does not define the symbol i386 anymore if invoked directly. The imake templates fail if this is not defined.
The best solution is upgrading to XFree86-3.3.2, which uses a slightly different way of setting its configuration information. Another possibility is adding the line #define i386Architecture 1 to the file /usr/lib/X11/config/host.def (not tested).
- I can't compile gcc-2.8.1; cpp returns an error?!?
Check that you LD_LIBRARY_PATH variable does not contain . or starts or ends with a colon, or has two colons after each other.
- When I compile ld.so, I can't run anything anymore!
See the ld.so page for a solution (you need at least version 1.9.6).
- I get many
undefined reference errors in my C++ programs; it did work with gcc-2.7.x.y!
Try adding -lg++ to the link flags; libg++ is no longer automatically linked in.
Check you use g++, not gcc during the linking phase. Even if you do everything at once (gcc hallo.cc -o hallo no longer works).
- I succesfully compiled my kernel with gcc-2.8.1, but now X-windows won't run anymore!
Apply this patch to your kernel (tested for 2.0.35, but it should work for any 2.0 kernel).
- I received this nice binary-only application, but can't run it!
It may be an old a.out (libc4) application. Read in this recent mail how you can execute it.
- ldd gives real strange output, sometimes...
The ldd script that comes with glibc-2.0.6 handles libc5 executables incorrectly, resulting in strange output. You are probably better off if you always use the ldd that comes with ld.so-1.9.9. Implement this by deleting or renaming /usr/i486-linux-libc6/bin/ldd
