[tulip-bug] Errors on macro definitions on kern_compat.h header

[Donald Becker]

On Tue, 5 Dec 2000 Maciej_Samsel@notes.amdahl.com wrote:

> I have a problem with compilation of the tulip.c and pci-scan.c files. The
> GCC compiler reports the same problem on the macro definitions at line 173
> and 177 of kern_compat.h
> 
> I use Caldera Systems  eDesktop 2.4 that is one of major distributions (I
> guess second after Red Hat). It seems that I have all header files. Here is
> the listing of what I get on the screen:

This is a compiler bug.  (Really a preprocessor bug.)
The usual report is with a Red Hat system with an updated 'gcc'.

> ________________________
> gcc -DMODULE -D__KERNEL__ -o6 -c tulip.o
> 
> In file included from tulip.c:162:
> kern_compat.h:173: parse error before `0'
> kern_compat.h:177: warning: parameter names (without types) in function
> declaration
> kern_compat.h:177: conflicting types for `mark_bh'

This code correct.
The work-around to the gcc bug is adding an extra space (!?).
See
  ftp://www.scyld.com/pub/network/kern_compat.h

> By the way, I noticed that the kern_compat.h was modified (as the only one
> file) several days ago (November 28, 2000). Could you please provide at
> least one level of backup (old version) files so people have chance not
> meet only new problems, but also revert to older, perhaps compilable
> version of source code?

This is a compiler bug.  I have covered this many time, including several
times in this list.  Compiler bug. Compiler bug. Compiler bug.  Not a driver
bug.  I updated kern_compat.h, but an updated source RPM is waiting for
actual driver bugs to be confirmed as fixed.

> This is a bit annoying as some major networking hardware manufacturers
> (Linksys and my card is LNK100TX) and major Linux distros like Caldera
> Systems recommend your modules in tech support. This does not seem really
> serious platform if at least testing is not in right place before release
> (well, I did not expect tech. support from Open Source software).

Scyld provides commercial support for these drivers, both on the Scyld
distribution and for other distributions.
What is your customer support number?

> This is
> enough frustrating that after 8-9 hours of developing commercial software
> on freak'n Windows instead of having pleasure of working with Linux at home
..
> programming background. But at least if they need to recompile  some
> software (which I believe should be provided as binaries to avoid whole
> hussle - this is part of real modularization I guess) then lets make simple

Wait, follow the money here:
You paid for Caldera packaging and support.
Caldera pointed you to Scyld.  You expect Scyld to write the driver,
package it for someone else's distribution, and answer questions about
Caldera's bug.  All for free, while Caldera is collecting the revenue.

Read your own letter here: you questioned the seriousness of Linux and
claimed that Scyld should do a better job of providing free support.

> Could you help me and I guess many other to come soon? Give me a tip what
> is wrong with my compileation, fix definititions in the header file and/or
> put older header files in some backup of previos versions online.

Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Second Generation Beowulf Clusters
Annapolis MD 21403			410-990-9993