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

Bug#175025: dev_t problems with non-gcc compilers



On Thu, Jan 02, 2003 at 06:31:13PM +0200, Timo Sirainen wrote:
> On Thu, 2003-01-02 at 18:09, Ben Collins wrote:
> > > // bits/types.h
> > > typedef __DEV_T_TYPE __dev_t;	/* Type of device numbers.  */
> 
> > Unless something drastic changed between 2.3.1-5 and 2.3.1-8, your
> > headers are broken. I show this:
> > 
> > typedef __u_quad_t __dev_t;             /* Type of device numbers.  */
> 
> Yes, my -5 looks the same in another computer.
> 
> > If in fact your headers are pristine from 2.3.1-8, then it means the
> > glibc folks decided they weren't going to support compilers that didn't
> > support long long, and forgot the change sysmacros.h to reflect that.
> 
> Looks like it. Just checked another computer with -8 and it had the same
> __DEV_T_TYPE change.

Ok, then the fix is to just change sysmacros.h to only use the long long
enabled macros by default.

> > > tcc doesn't do preprocessing separately.
> > Then if tcc can't show you the preprocessing step, it's broken.
> 
> Does C require that? Anyway, tcc's point is to be as fast as possible so
> it does everything at once.

C doesn't require it, but not being able to see the steps of compilation
makes it hard to debug code (bad inclusions and defines that trump other
defines). I'd expect any half decent compiler to show me the
pre-processed data and the assembler (does tcc do assembly too, or does
it pass that to gnu AS?)

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/



Reply to: