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

[M&M Samsel]

Okay I understand it might be a preprocessor problem. I will check that 
myslef, but I was suspecting some problem with preprocessor (although 
serious compilers do not have such basic problems after quite a while).

Now, who told you I was expecting free support. Read my post carefully 
again so you will find sentence: "well I did not expect...." and basically 
I expected that this was Open Source Software or GPL. The thing is that I 
do not care what is your relation with some distibution so please do not 
whine who takes money and who does not (I know what I would do). This is 
your business and your problem not mine. If Caldera and Linksys directs to 
you then I believe that I should expect fair treatment and help... even if 
I don't have to pay you money (I hope that not for fact that I should play 
role of little Joe programmer and compile some modules myself with buggy 
compiler that was provided to my by referring distibution).

You see I  have about 10 years of commercial development experience and 
pretty much know business procedures from huge corporations and business 
midgets and what I should expect or not.

You also misses one point that people do not get support numbers from 
distributions (at least from Caldera Systems)  unless they have support 
contract. Do I have a contract for home use that probably costs a lot 
(thousands of dollars)? Just answer the question yourself. I can provide 
you only with my serial number or so if it is printed on manual or 
somewhere. The support is for 90 days I believe.

Thanks for the information though.

At 04:32 PM 12/5/00 -0500, you wrote:
>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
>
>
>_______________________________________________
>tulip-bug mailing list
>tulip-bug@scyld.com
>http://www.scyld.com/mailman/listinfo/tulip-bug