bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Strange output of gcc -E on GNU/Hurd


From: Thomas Schwinge
Subject: Re: Strange output of gcc -E on GNU/Hurd
Date: Mon, 16 Jul 2012 16:48:42 +0200
User-agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/23.3.1 (i486-pc-linux-gnu)

Hi Barry!

On Mon, 16 Jul 2012 10:25:27 -0400, Barry deFreese <bdefreese@verizon.net> 
wrote:
> On 7/16/2012 3:43 AM, Thomas Schwinge wrote:
> > On Sun, 15 Jul 2012 16:32:06 -0400, Barry deFreese <bdefreese@debian.org> 
> > wrote:
> >> In looking at libprelude it generates a lot of files using gawk.  The 
> >> attached file is
> >> generated from gawk and then is run through gcc -E.
> >> 
> >> On GNU/Hurd, I get significantly different results than I do from 
> >> GNU/Linux.  Anyone have a
> >> clue why that might be or where I would look to "debug" this?
> > 
> > What errors do you get?
> 
> I'm not getting any errors it is just that the output is so radically 
> different that the package
> that processes the output files is having problems.

OK -- so a later compilation stage is choking on this and thus emitting
error messages?

> Attached is foo.h processed by both hurd and linux.

Hurd:

> enum __error_t_codes
> {
> 
> 
>  EPERM = ((0x10 << 26) | ((1) & 0x3fff)),

> ((0x10 << 26) | ((1) & 0x3fff)) PRELUDE_ERROR_EPERM

Linux:

> 1 PRELUDE_ERROR_EPERM

So i'm guessing that either the later compilation stage is choking on the
presence of the Hurd version's enum definition, or on the Hurd's
pecularity of E* values and thus the PRELUDE_ERROR_* values not being
simple numerals.  Whatever it is (and whatever that code is being used
for...) it needs to be extended to cope with this.


Grüße,
 Thomas

Attachment: pgpBJ1PHperz8.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]