Fixincludes - some analysis

Greg Schafer gschafer at
Fri Jan 24 20:01:50 PST 2003

On Sat, Jan 25, 2003 at 11:49:49AM +1100, Greg Schafer wrote:
> Ok, after having looked at all the above, who is prepared to put their cock
> on the block and confirm that we can do without fixincludes in Ch 6?

I've studied this a bit more and can clear up some of the above at least.
Looking at gcc -v foo.c is very educational :-)

With gcc-3.2.1, compiling foo.c with -v shows the following excerpt:-

 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/cc1 -lang-c -v -D__GNUC__=3
-Dunix -D__gnu_linux__ -Dlinux -D__ELF__ -D__unix__ -D__gnu_linux__
-D__linux__ -D__unix -D__linux -Asystem=posix -D__NO_INLINE__
-D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__
-D__tune_i686__ -D__tune_pentiumpro__ foo.c -quiet -dumpbase foo.c -version
-o /tmp/ccNaiK5C.s

Most of all those -D cpp macros come from the gcc specs file. You'll notice
in the above that there is:-

  -Dlinux  -D__linux__  -D__linux

and also:-

  -Di386  -D__i386  -D__i386__

Therefore it would seem that gcc is already accounting for some of the
variants that fixincludes is trying to fix! I smell some redundancy here.
Fixincludes is starting to look less necessary (for our purposes at least).

Also, the reason the headers that contain those defines are not fixed in 3.3
or 3.4 is that it looks like the CPP specs mechanism has changed in the
newer compilers (check out i386.c and i386.h).

Getting there..

Unsubscribe: send email to listar at
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list