[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061206135931.GB8693@postel.suug.ch>
Date: Wed, 6 Dec 2006 14:59:31 +0100
From: Thomas Graf <tgraf@...g.ch>
To: Jakub Jelinek <jakub@...hat.com>
Cc: Ulrich Drepper <drepper@...hat.com>,
David Woodhouse <dwmw2@...radead.org>,
"Joseph S. Myers" <joseph@...esourcery.com>,
netdev@...r.kernel.org, libc-alpha@...rceware.org, akpm@...l.org,
"David S. Miller" <davem@...emloft.net>
Subject: Re: Kernel header changes break glibc build
* Jakub Jelinek <jakub@...hat.com> 2006-12-06 14:43
> On Wed, Dec 06, 2006 at 01:01:54PM +0000, David Woodhouse wrote:
> > No. They _are_ doing it right -- they're running 'make headers_install'
> > against the 2.6.19 kernel and only _now_ are they finding that we broke
> > it without even the courtesy of a warning, let alone any consultation.
> >
> > If _we_ had done it right, then they would have been warned when we
> > decided to change this, and we wouldn't have just released 2.6.19 with
> > changes which break the glibc build.
>
> Yeah, I don't think glibc was doing anything wrong and the 2.6.19
> changes to the make headers_install created headers mean we'd
> either need to add configure checks for the headers (we can't
> simply #include <linux/if_addr.h> because that header didn't
> exist pre 2.6.19 and IF*_{RTA,PAYLOAD} macros were dropped anyway),
> or we need to start defining this ourselves.
Are you suggesting that the kernel has to keep macros around which
are of no use to the kernel itself just because glibc uses them?
What's wrong with copying the headers and ship them? Every glibc
release is based on some kernel version anyway and its no problem
to run glibc compiled with a 2.6.19 header set on a 2.6.18 kernel.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists