Your message dated Sun, 1 Jun 2003 16:06:38 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Bug#194242: acknowledged by developer (Re: Bug#194242:
drivers/atm/ambassador.c:301:21: pasting "." and "start" does not give a valid
preprocessing token)
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 21 May 2003 17:43:20 +0000
>From [EMAIL PROTECTED] Wed May 21 12:43:19 2003
Return-path: <[EMAIL PROTECTED]>
Received: from smtp.telefonica.net (tnetsmtp1.mail.isp) [213.4.129.135]
by master.debian.org with esmtp (Exim 3.35 1 (Debian))
id 19IXcU-0004pB-00; Wed, 21 May 2003 12:43:18 -0500
Received: from 986883592.telefonica.net ([80.24.119.61]) by
tnetsmtp1.mail.isp (terra.es) with ESMTP id HF8ZW100.P3Y; Wed,
21 May 2003 19:43:13 +0200
Subject: Can't compile kernel 2.4.20
From: Jose Antonio Salgueiro <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Content-Type: text/plain
Organization:
Message-Id: <[EMAIL PROTECTED]>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4
Date: 21 May 2003 19:43:21 +0200
Content-Transfer-Encoding: 7bit
Delivered-To: [EMAIL PROTECTED]
X-Spam-Status: No, hits=-12.3 required=4.0
tests=BAYES_01,HAS_PACKAGE,USER_AGENT_XIMIAN
autolearn=ham version=2.53-bugs.debian.org_2003_05_20
X-Spam-Level:
X-Spam-Checker-Version: SpamAssassin 2.53-bugs.debian.org_2003_05_20
(1.174.2.15-2003-03-30-exp)
Package: gcc
Version: 3.3-1
Compiling kernel 2.4.20
make clean
make dep
make bzImage
..ers/video/video.o drivers/i2c/busses/i2c-busses.o
drivers/i2c/chips/i2c-chips.o \
net/network.o \
/usr/src/linux-2.4.20/arch/i386/lib/lib.a
/usr/src/linux-2.4.20/lib/lib.a
/usr/src/linux-2.4.20/arch/i386/lib/lib.a \
--end-group \
-o vmlinux
net/network.o(.text+0xd887): In function `rtnetlink_rcv':
: undefined reference to `rtnetlink_rcv_skb'
make: *** [vmlinux] Error 1
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux lucas.casa 2.4.20 #5 jue abr 17 19:25:45 CEST 2003 i686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (ignored: LC_ALL set)
Versions of packages gcc-3.3 depends on:
ii binutils 2.14.90.0.2-0.1 The GNU assembler, linker
and bina
ii cpp-3.3 1:3.3-2 The GNU C preprocessor
ii gcc-3.3-base 1:3.3-2 The GNU Compiler Collection
(base
ii libc6 2.3.1-17 GNU C Library: Shared
libraries an
ii libgcc1 1:3.3-2 GCC support library
How often does this happen?
Always
---------------------------------------
Received: (at 194196-done) by bugs.debian.org; 1 Jun 2003 14:09:56 +0000
>From [EMAIL PROTECTED] Sun Jun 01 09:09:54 2003
Return-path: <[EMAIL PROTECTED]>
Received: from mail.cs.tu-berlin.de [130.149.17.13]
by master.debian.org with esmtp (Exim 3.35 1 (Debian))
id 19MTWy-0008Ck-00; Sun, 01 Jun 2003 09:09:52 -0500
Received: from bolero.cs.tu-berlin.de ([EMAIL PROTECTED] [130.149.19.1])
by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id QAA07479;
Sun, 1 Jun 2003 16:06:38 +0200 (MET DST)
Received: (from [EMAIL PROTECTED])
by bolero.cs.tu-berlin.de (8.11.6+Sun/8.9.3) id h51E6cC28935;
Sun, 1 Jun 2003 16:06:38 +0200 (MEST)
From: Matthias Klose <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[EMAIL PROTECTED]>
Date: Sun, 1 Jun 2003 16:06:38 +0200
To: Segher Boessenkool <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
[EMAIL PROTECTED]
Cc: "Brian M. Carlson" <[EMAIL PROTECTED]>,
"Dr. David Alan Gilbert" <[EMAIL PROTECTED]>,
Herbert Xu <[EMAIL PROTECTED]>
Subject: Re: Bug#194242: acknowledged by developer (Re: Bug#194242:
drivers/atm/ambassador.c:301:21: pasting "." and "start" does not give a valid
preprocessing token)
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
X-Mailer: VM 7.03 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid
Delivered-To: [EMAIL PROTECTED]
X-Spam-Status: No, hits=-21.2 required=4.0
tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,
REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_VM
version=2.53-bugs.debian.org_2003_05_24
X-Spam-Level:
X-Spam-Checker-Version: SpamAssassin 2.53-bugs.debian.org_2003_05_24
(1.174.2.15-2003-03-30-exp)
Closing these reports. Please submit bugs against the various kernel
source packages, either to fix the bug or to select a compiler, which
still accepts this coding style.
Segher Boessenkool writes:
> Brian M. Carlson wrote:
> >>The standard says this is undefined behaviour. The code never "worked",
> >>but by pure accident produced the expected result.
> >
> > The compiler is *permitted* to make demons fly out of my nose, but if it
> > did that, I'd file a bug on it asserting that it shouldn't do that
> > either. Saying that the code never worked is at best, pedantic, and at
> > worst, false. The code compiled with gcc 3.2 into an ELF relocatable and
> > fails to do so with gcc 3.3.
>
> 3.2 (and some versions before it) warned that you shouldn't
> rely on this working. Now, with 3.3, it indeed stopped working.
> This is neither a surprise nor a problem.
>
> >>>If a .c file doesn't turn into a .o file, and it did with 3.2 [0], that's
> >>>a regression, and therefore a bug. You can argue for all eternity
> >>
> >>Not if it isn't a valid C source file.
> >
> > Neither #warning nor #error are valid C syntax either. But I'm sure
>
> #error _is_ valid C syntax.
>
> > you'll find them in a great deal of C source files. Is it your
> > contention that gcc should outright reject every file which does not
> > comply with the C standard?
>
> No, but it sure can't be expected to accept every erroneous
> construct and "do the right thing" with it, whatever that
> may be.
>
> > And if so, which version of the C standard is that?
>
> The version that was specified on the command line, of course.
>
> > If not, what criteria are we to use to determine whether to
> > reject files which have syntax errors?
>
> Every syntax error is a hard error.
>
> > Are you trying to convince me that it is a case of sheer stupidity? I
> > don't think that's what's happening here.
>
> You're trying hard to suggest it is, though.
>
>
> Segher
>
>
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
