Fixincludes - some analysis

Greg Schafer gschafer at zip.com.au
Fri Jan 24 16:49:49 PST 2003


Hi

Could some knowledgable programmers look at this please?

First some background for the uninitiated:
During the gcc installation, a procedure called "fixincludes" is run which
"fixes" up various headers on the system and then copies the "fixed" headers
into gcc's own internal include dir so that the "fixed" ones get picked up
in the include search path before the "unfixed" ones. You can see gcc's
include search path when you compile with -v e.g. gcc -v foo.c. Here's an
excerpt with gcc-3.2.1 from my system:-

ignoring nonexistent directory "/usr/i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/include  <-- fixed headers end up here
 /usr/include
End of search list.

Sidenote: I don't understand at all why /usr/local/include comes first in
the search path. This seems very counter-intuitive to me. The gcc page at:-
http://gcc.gnu.org/install/configure.html   contains some commentary on why
this is so but I still don't get it.

As we all know, LFS is not installing the "fixed" headers in Ch 5 gcc coz it
makes no sense to pollute the new chroot environment with headers from the
host system (it was in fact causing breakage on some host systems). But we
are still installing the "fixed" headers in Ch 6. Personally, I don't
install the "fixed" headers in Ch 6 (like a few other folk around here) and
haven't noticed any breakage attributable to it.

But I have a few other compilers installed in /opt which I use for testing
purposes. I've taken a look at what gets "fixed" and present this info
below:-

----------------------------------------
stdio.h  (from glibc)

@@ -73,9 +82,9 @@
 
 #ifdef __USE_XOPEN
 # ifdef __GNUC__
-#  ifndef _VA_LIST_DEFINED
-typedef _G_va_list va_list;
-#   define _VA_LIST_DEFINED
+#  ifndef _DUMMY_VA_LIST_DEFINED
+typedef _G_va_list __not_va_list__;
+#   define _DUMMY_VA_LIST_DEFINED
 #  endif
 # else
 #  include <stdarg.h>

So what's doing here?? If you go hunting throught the code in the gcc source
dir:-  gcc/fixinc  you might find some clues but this varags stuff makes no
sense to me.  Incidentally, 3.3 and 3.4 perform the same fix. 2.95.4 doesn't
do the fix at all.

----------------------------------------
curses.h ncusrses.h  (from ncurses)

@@ -295,7 +304,9 @@
 #endif
 
 #ifndef _WCHAR_T
+#ifndef __cplusplus
 typedef unsigned long wchar_t;
+#endif
 #endif /* _WCHAR_T */
 #ifndef _WINT_T
 typedef long int wint_t;

The intent of this one looks clear. Don't do the typedef if included in c++
code. I have no idea if this is good or bad. Again, 3.3 and 3.4 perform the
same fix. 2.95.4 doesn't do the fix at all.

----------------------------------------
zconf.h  (from zlib)

@@ -51,7 +60,7 @@
 #if (defined(_WIN32) || defined(__WIN32__)) && !defined(WIN32)
 #  define WIN32
 #endif
-#if defined(__GNUC__) || defined(WIN32) || defined(__386__) || defined(i386)
+#if defined(__GNUC__) || defined(WIN32) || defined(__386__) || defined(__i386__)
 #  ifndef __32BIT__
 #    define __32BIT__
 #  endif

Looks clearly like a bug fix. But surely it won't matter to us because we
are using __GNUC__ anyway right? Neither 3.3, 3.4 or 2.95.4 offer to fix
this header. This begs the obvious question, is the header busted or not?

----------------------------------------
linux/a.out.h  (from kernel)

@@ -127,7 +136,7 @@
 #define SEGMENT_SIZE PAGE_SIZE
 #endif
 
-#ifdef linux
+#ifdef __linux__
 #include <asm/page.h>
 #if defined(__i386__) || defined(__mc68000__)
 #define SEGMENT_SIZE   1024

Dunno. Who uses a.out anyway? Dunno. Again, neither 3.3, 3.4 or 2.95.4 offer
to fix this header.

----------------------------------------
linux/nls.h  (from kernel)

 #ifndef _LINUX_NLS_H
 #define _LINUX_NLS_H
 
 #include <linux/init.h>
 
 /* unicode character */
+#ifndef __cplusplus
 typedef __u16 wchar_t;
+#endif
 
 struct nls_table {

Looks similar to the ncurses one above. Widechar c++ stuff. Dunno. 3.3 and
3.4 offer the same fix but not 2.95.4.

----------------------------------------
linux/zconf.h  (from kernel)

@@ -8,7 +17,7 @@
 #ifndef _ZCONF_H
 #define _ZCONF_H
 
-#if defined(__GNUC__) || defined(__386__) || defined(i386)
+#if defined(__GNUC__) || defined(__386__) || defined(__i386__)
 #  ifndef __32BIT__
 #    define __32BIT__
 #  endif

This is just the kernel's version of zlib and is the same fix as above.
Again, neither 3.3, 3.4 or 2.95.4 offer to fix this header.

----------------------------------------
X11/Xlib.h  (from xfree86)

@@ -75,9 +84,11 @@
 #include <stdlib.h>
 #else
 /* replace this with #include or typedef appropriate for your system */
+#ifndef __cplusplus
 typedef unsigned long wchar_t;
 #endif
 #endif
+#endif
 
 #if defined(ISC) && defined(USE_XMBTOWC)
 #define wctomb(a,b)    _Xwctomb(a,b)

See ncurses above. Again, 3.3 and 3.4 perform the same fix. Dunno about
2.95.4 as I suspect X wasn't installed when I installed gcc-2.95.4. But X
isn't installed at time of normal LFS installation anyway so...

----------------------------------------
X11/Xos.h X11/Xos_r.h X11/Xosdefs.h X11/Xthreads.h  (from xfree86)

just more of the same:-

(defined(i386)  ->  (defined(__i386__)
(defined(linux) ->  (defined(__linux__)
#ifdef i386     ->  #ifdef __i386__

type of thing. 3.3 and 3.4 don't offer the fixes.

----------------------------------------

One thing I haven't done yet is see how the distro's handle these
fixincludes thingamys. Might be worthwhile checking out.

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?

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



More information about the lfs-dev mailing list