[tulip-bug] compilation problems

[Keith Warno]

trent brown wrote:
> 
> Got it thanks to your archives! I just needed to include the path in the
> compile options  "-I/usr/src/linux/include".
> 
> thanks for the drivers
> Trent


Greetings:

I spoke to Trent Brown via email about this problem over the weekend
because his problem was similar, if not identical, to the one I ran
into.

The Scyld site talks about using the -I flag for Redhat systems because
of broken/wrong kernel headers.  I didn't see why this should interest
me because I don't use a redhat box.  I'm running SuSE 6.2.  Out of
curiosity, I threw in the -I/usr/src/linux/include when building tulip.o
& pci-scan.o and the previous compile problems (similar to Trent's) went
away.  Very interesting, considering that the -I workaround was to get
around some strange redhat kernel choices, and I'm running 2.2.17 and
have only 2.2.17 sources installed.

The only thing "different" about the box I did the build on is that I
built gcc 2.95.2 and binutils 2.10 from source tarballs.  I had made a
post about this in the past but now I'm wondering if anyone else out
there has run into tulip.c/pci-scan.c compile problems dude to the same
source, which I believe I'v pin-pointed.  A bit more detail:

I wondered why -I/usr/src/linux/include would make the problem go away. 
The only thing that looks useful in /usr/src/linux/include is a symlink
called asm.  OK fine.  So the headers in *this* asm dir must be getting
used instead of *some other* ones.  Hmm, where else do we have asm
headers??

As stated, I installed gcc from tarballs.  During the gcc build and
install, it likes to ``fix'' various system headers files.  Output of
ccp -v to show the header search path:

kw@foo[pts/2]:/usr/src/linux/include$ cpp -v
Reading specs from
/usr/local/gcc/2.95.2/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs
gcc version 2.95.2 19991024 (release)
 /usr/local/gcc/2.95.2/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/cpp -lang-c
-v -D__ELF__ -Dunix -D__i386__ -Dlinux -D__ELF__ -D__unix__ -D__i386__
-D__linux__ -D__unix -D__linux -Asystem(posix) -Acpu(i386)
-Amachine(i386) -Di386 -D__i386 -D__i386__ -Di686 -Dpentiumpro -D__i686
-D__i686__ -D__pentiumpro -D__pentiumpro__ -
GNU CPP version 2.95.2 19991024 (release) (i386 Linux/ELF)
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include

/usr/local/gcc/2.95.2/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/../../../../i686-pc-linux-gnu/include
 /usr/local/gcc/2.95.2/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/include
 /usr/include
End of search list.
The following default directories have been omitted from the search
path:

/usr/local/gcc/2.95.2/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/../../../../include/g++-3
End of omitted list.


(sorry for any line wrapping that has happened)


The path of interest is
/usr/local/gcc/2.95.2/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/include . 
(This is only for my machine!  Not yours :)  Note that it's before
/usr/include/ in the search path.  I hop into this dir, and see a
README:


This README file is copied into the directory for GCC-only header files
when fixincludes is run by the makefile for GCC.

Many of the files in this directory were made from the standard system
header files of this system by the shell script `fixincludes'.
They are system-specific, and will not work on any other kind of system.
They are also not part of GCC.  The reason for making the files here
is to fix the places in the header files which use constructs
that are incompatible with ANSI C.




OK fine.  So this is the fixincludes dir.  I poke around in the dir a
bit more, and notice an ``asm'' dir.  Hmmm.  Also an asm dir in
/usr/src/linux/include/.  Any sparks flying yet?

Look in the asm dir and find just one header ``posix_types.h'':


/* This file fixes __FD_ZERO bug for glibc-1.x. */
#ifndef _POSIX_TYPES_H_WRAPPER
#include <features.h>
#include_next <asm/posix_types.h>

#if defined(__FD_ZERO) && !defined(__GLIBC__)
#undef __FD_ZERO
#define __FD_ZERO(fdsetp) \
  do { \
    int __d0, __d1; \
                __asm__ __volatile__("cld ; rep ; stosl" \
                        : "=&c" (__d0), "=&D" (__d1) \
                        : "a" (0), "0" (__FDSET_LONGS), \
                          "1" ((__kernel_fd_set *) (fdsetp)) :"memory");
\
  } while (0)
#endif

#define _POSIX_TYPES_H_WRAPPER
#endif /* _POSIX_TYPES_H_WRAPPER */



#include_next?  eh?  Oh ok, that sucks in the next <asm/posix_types.h>
in the path... which would be /usr/include/asm/posix_types.h.  (which is
the same as /usr/src/linux/include/asm/posix_types.h).  Hmm, this is
what happens *without* the -I/usr/src/linux/include/ flag.  *WITH* the
flag, we're not gonna get this funky wrapper header (because
/usr/src/linux/include/ will be *before* the fixincludes dir in the
search path).  Could it be that this wrapper is breaking things???  Is
the wrapper broken?

Apparently so, if I'm to believe that Mr Becker's code is truly rock
solid.  If the fixincludes asm dir is removed from the header search
path (via renaming or whatever), tulip.c compiles fine.  When it is in
the path, tulip.c compile breaks.

A little further poking and it appears that the inclusion of features.h
by the wrapper is what's really causing the compile to blow up.  Then
again, I'm probably just on crack.


Now if anyone else out there can confirm any of this Monday morning
rambling, I'd be glad to hear it.


Regards,
kw