[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
pgpBJ1PHperz8.pgp
Description: PGP signature