Re: Second 4.6.0 release candidate

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

 



On Tue, 21 Mar 2006, Tom Williams wrote:
Marc Aurele La France wrote:
gcc-4.1.0, and glibc-2.3.4.  Looks like the 2.6.16 kernel changed
"unsigned long" types in the "input_device_id" struct to
kernel_ulong_t.  I don't know if the XFree86 source needs to be tweaked
any to build against a 2.6.16 kernel, but I'm making everyone aware of
this anyway.  :)

Please see http://www.mail-archive.com/devel%40xfree86.org/msg07674.html

Thanks for the link to the thread.  So, I guess the patch submitted by
the thread starter was rejected?

Yes, it was. Kernel headers have been gradually breaking for a _very_ long time, WRT their #include'ing by userland apps. Instead of changing the kernel build system to monitor the situation, kernel hackers have decided re-design /usr/src/linux/include/ from scratch. Last I checked, a first implementation of this rework is scheduled to show up in 2.7 kernels.

Your message refers to using kernel headers when building glibc.  Why
would that be the issue for me since I haven't touched glibc since I
first installed it, which was after it first came out?  Is the idea
being when I upgraded to glibc-2.3, it used kernel headers *back then*
so each subsequent upgrade continued to do so?

"I haven't touched glibc since I first installed it" is a contradiction of "when I upgraded to glibc-2.3".

Be that as it may, there are several possibilities here. You might still have the old /usr/include/{linux,asm} -> /usr/src/linux/include/{linux,asm} symlinks. Or you might have omitted upgrading the laundered kernel header package for your distribution and/or kernel when upgrading glibc (even assuming it was from binaries). Or you rebuilt glibc from source pointing it directly at unlaundered kernel headers you had installed at the time. Or, or, ...

In any case, I am loathe to commit an ever-increasing set of workarounds for a problem kernel maintainers not only admit to, but also have yet to fix. This whether or not such workarounds are always possible, which isn't the case.

Marc.

+----------------------------------+-----------------------------------+
|  Marc Aurele La France           |  work:   1-780-492-9310           |
|  Academic Information and        |  fax:    1-780-492-1729           |
|    Communications Technologies   |  email:  tsi@xxxxxxxxxxx          |
|  352 General Services Building   +-----------------------------------+
|  University of Alberta           |                                   |
|  Edmonton, Alberta               |     Standard disclaimers apply    |
|  T6G 2H1                         |                                   |
|  CANADA                          |                                   |
+----------------------------------+-----------------------------------+
XFree86 developer and VP.  ATI driver and X server internals.
_______________________________________________
XFree86 mailing list
XFree86@xxxxxxxxxxx
http://XFree86.Org/mailman/listinfo/xfree86

[Index of Archives]     [X Forum]     [Xorg]     [XFree86 Newbie]     [IETF Announce]     [Security]     [Font Config]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux Kernel]

  Powered by Linux