reopen 220814 reassign 220814 xfree86 severity 220814 grave retitle 220814 xfree86: FTBFS on hppa,sparc: gymnastics necessary to escape gratuitous structure member renaming in Linux kernel tag 220814 + upstream help thanks On Fri, Nov 14, 2003 at 08:17:35PM +0000, James Troup wrote: > Hi, > > I haven't had a chance to investigate this yet, so no bug, but I > thought I'd at least warn you. This was the 3rd attempt on vore. The > first had an out-of-date linux-kernel-headers installed in the chroot, > so I freshened the chroot and retried. #2 got bitten by the sparc32 > fuckage (see sparc-utils changelog for details). #3 (below) was in an > up-to-date chroot (with working sparc32) > > | Automatic build of xfree86_4.2.1-14 on vore by sbuild/sparc 1.170.4 > | Build started at 20031114-1051 > | ****************************************************************************** > > [...] > > | ** Using build dependencies supplied by package: > | Build-Depends: dpkg (>= 1.7.0), cpp-3.2, flex-old, bison, bsdmainutils, groff, zlib1g-dev | libz-dev, libncurses5-dev | libncurses-dev, libpam0g-dev | libpam-dev, libfreetype6-dev, libpaperg, libstdc++5-dev | libstdc++-dev, tetex-bin, po-debconf, debhelper (>= 4.1.16), html2text, libglide2-dev (>> 2001.01.26) [i386], libglide3-dev (>> 2001.01.26) [alpha i386], kernel-headers-2.4 | hurd | freebsd | netbsd | openbsd > > [...] > > | lnx_io.c: In function `KIOCSRATE_ioctl_ok': > | lnx_io.c:128: error: structure has no member named `period' > | lnx_io.c:130: error: structure has no member named `period' > | lnx_io.c:131: error: structure has no member named `period' > | make[8]: *** [lnx_io.o] Error 1 > > A complete build log can be found at > http://buildd.debian.org/build.php?arch=sparc&pkg=xfree86&ver=4.2.1-14 > > -- > James > > > -- > To UNSUBSCRIBE, email to debian-x-request@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org > 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. > 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. -- G. Branden Robinson | Exercise your freedom of religion. Debian GNU/Linux | Set fire to a church of your branden@debian.org | choice. http://people.debian.org/~branden/ |
Attachment:
signature.asc
Description: Digital signature