Steve Langasek writes: > On Fri, 30 Mar 2001, David Schleef wrote: > > > On Fri, Mar 30, 2001 at 02:34:48PM -0600, Steve Langasek wrote: > > > > > Any comment on the /usr/lib/gcc-lib/*/*/include files? I > > > > noticed that the gcc build process is supposed to be able to > > > > create float.h, limits.h, etc., but that doesn't seem to > > > > be currently part of the build process. > > > > These files were created and installed correctly on my system when I > > > built the > > > cross-compilers I'm using (see below). Has this changed in subsequent > > > releases? > > > Goes back to the previous question. The build process fails if > > these files aren't already installed for the target architecture. > > It works fine, for example, if you have a previous version of > > the cross-compiler installed. > > > I've attached the last 100 lines of the build log, I'll send the > > rest (2 MB) if you want. > > Ah... Yes, I recognize these symptoms now. I had to run strace against the > build process to find it myself. You see, gcc doesn't need the include > files to be in /usr/lib/gcc-lib, but it does need the *directories* to be > there -- not because it needs anything in those directories, but because it > constructs its include paths by appending ../../../../<arch> to > /usr/lib/gcc-lib/<arch>/<version> -- and > /usr/lib/gcc-lib/m68k-linux/2.95.3/../../../../m68k-linux/include/ (ugly!) > will only point to /usr/m68k-linux/include/ if the directories in > /usr/lib/gcc-lib/ exist, regardless of whether there's anything in them! > > So yes... this is a rather vexing bug in the build process for gcc 2.95.3. > For me, it was easier to work around it by creating the directories instead > of > trying to fix gcc. :/ I don't know if this has been fixed in gcc 3.0?
A policy compliant workaround could be a cross-gcc-2.95-base package, which contains these directories.
