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

Bug#220814: xfree86_4.2.1-14(unstable/sparc): FTBFS



On Mon, Jan 12, 2004 at 12:12:51PM -0500, Branden Robinson wrote:
> On Thu, Jan 08, 2004 at 03:24:10PM -0500, Daniel Jacobowitz wrote:
> > OK, here's what I think is happening.
> > 
> > X is working around a changed type in kd.h by #define rate period.
> 
> A changed type?  To date I have only heard this characterized as a
> change to the name of a structure member.

That's a change in the type of the structure, my friend :)

> > Then there's something in kbio.h which uses rate.
> 
> Uh, okay.
> 
> > I don't see this as a kernel headers bug.
> 
> ...even though on some architectures, the structure member is renamed,
> and on others, it isn't?  That seems to be what elmo is saying from the
> IRC log.
> 
> > Fix the rates to be periods properly.
> 
> Unfortunately, I don't know what you mean by "properly".
> 
> > Or do something like
> > #if defined(LINUX_VERSION_CODE) && defined(KERNEL_VERSION)
> > # if LINUX_VERSION_CODE >= KERNEL_VERSION(2,5,42)
> > #  define kd_rate period
> > # else
> > #  define kd_rate rate
> > # endif
> > #else
> > # define kd_rate rate
> > #endif
> > 
> > And then change the appropriate "rate" accesses to "kd_rate".  The two
> > structures are different.  I bet the latter rate really IS a rate, not
> > a period.
> 
> What do you mean by the "latter rate"?  I thought the same thing was
> being referred to in both cases: the kbd_rate struct.

That is the center of the confusion.

asm-sparc/kbio.h:

/* Used by KIOC[GS]RATE */
struct kbd_rate {
        unsigned char delay;    /* Delay in Hz before first repeat.  */
        unsigned char rate;     /* In characters per second (0..50).  */
};

linux/kd.h:
struct kbd_repeat {
        int delay;      /* in msec; <= 0: don't change */
        int period;     /* in msec; <= 0: don't change */
                        /* earlier this field was misnamed "rate" */
};

One of those is kbd_rate, the other is kbd_repeat.  They aren't the
same type.  I imagine from the errors that the X source file in
question uses both types.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer




Reply to: