From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <324fccf0703071321u4b5480f7nc8df88fce9aaa50b@mail.gmail.com>
Date: Wed,  7 Mar 2007 15:21:13 -0600
From: "John Osborne" <osborne6@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: [9fans] interesting potential targets for plan 9 and/or inferno
In-Reply-To: <20070307115042.GA54500@shodan.homeunix.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <45EDE39F.8060006@proweb.co.uk>
	<474b349ac6f7a20920261a714df9b8ef@proxima.alt.za>
	<32a656c20703062152n6a9bb7b1qfefa9b7827e3a9af@mail.gmail.com>
	<13426df10703062202g29819385h5d4fe3db57b9867c@mail.gmail.com>
	<32a656c20703062216h18c65028lba8cc6d8ccde8bbc@mail.gmail.com>
	<13426df10703062242q3cdc421fnb45a5e6342b8b5ee@mail.gmail.com>
	<20070307115042.GA54500@shodan.homeunix.net>
Topicbox-Message-UUID: 1a48ad88-ead2-11e9-9d60-3106f5b1d025

fwiw, stddef.h is part of the linux kernel headers... blame linus and
not the gcc guys.

On 3/7/07, Martin Neubauer <m.ne@gmx.net> wrote:
> * ron minnich (rminnich@gmail.com) wrote:
> > The isses of Python and gcc are not simply academic. They're part of
> > the DOE meal ticket.
>
> I happen to have lost what respect was left for gcc a couple of weeks ago
> when I tried to compile drawterm on a 64bit linux box. Gcc barfed on a
> malformed typedef in stddef.h. It might be the right thing nowadays, but a
> compiler not accepting a standard header (installed in a directory not only
> specific to said compiler but also to the compiler version) certainly is a
> bit gross.
>
> To be fair, the problem probably was the result of the combination of a
> 64bit (intel) architecture, the organisation of that specific distro, and
> the installed compiler, but I'm not sure it's even an excuse. (Testing,
> anyone?)
>
> So, while having a gcc port could be helpful for getting new users, the gcc
> folks should get their act together, rather then churning out ever new
> optimisation switches.
>
>         Martin
>
> P.S. The problem with drawterm was trivially fixed by commenting out the
> offending line as none of the drawterm code was using it.
>
>


-- 
John Osborne
osborne6@ieee.org/osborne6@gmail.com/jro@freeshell.org