[ANNOUNCE] linux-libc-headers 2.6.10.0

0 views
Skip to first unread message

Mariusz Mazur

unread,
Jan 8, 2005, 10:15:31 AM1/8/05
to lkml
Available at http://ep09.pld-linux.org/~mmazur/linux-libc-headers/
Changes:
- updated to 2.6.10
- switched to using svn and now ChangeLog is back :)
- some minor changes here and there (made some headers ansi C compatible)


Two weeks after 2.6.10, but you can blame Linus for releasing 2.6.10 just
before Christmas.

Like I've said two months ago - my scripts for testing new versions now do
separate asm-i386-ansi and asm-i386-noansi checks, so any ansi degradation in
linux or asm-i386 (like the one from 2.6.9) won't go unnoticed.

One more thing - llh is now officially one year old (first commits are from
December 2003). That's a long time for any hack to live. Especially a hack
this big and one that even has a couple of vendor specific variants. A couple
of discussions took place concerning this matter (in the last one Linus even
said, that he'll be accepting patches) and still I see no movement. I'd
really like to see glibc guys figuring out a way not to duplicate definitions
and structures from linux and starting to submit patches. That'd be a really
good (and much needed - glibc's and linux' headers conflict in lots of ugly
ways) first step.
Anybody?

Happy New Year.

--
In the year eighty five ten
God is gonna shake his mighty head
He'll either say,
"I'm pleased where man has been"
Or tear it down, and start again
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Randy.Dunlap

unread,
Jan 10, 2005, 11:09:14 AM1/10/05
to Mariusz Mazur, lkml
Mariusz Mazur wrote:
> Available at http://ep09.pld-linux.org/~mmazur/linux-libc-headers/
> Changes:
> - updated to 2.6.10
> - switched to using svn and now ChangeLog is back :)
> - some minor changes here and there (made some headers ansi C compatible)
>
>
> Two weeks after 2.6.10, but you can blame Linus for releasing 2.6.10 just
> before Christmas.
>
> Like I've said two months ago - my scripts for testing new versions now do
> separate asm-i386-ansi and asm-i386-noansi checks, so any ansi degradation in
> linux or asm-i386 (like the one from 2.6.9) won't go unnoticed.
>
> One more thing - llh is now officially one year old (first commits are from
> December 2003). That's a long time for any hack to live. Especially a hack
> this big and one that even has a couple of vendor specific variants. A couple
> of discussions took place concerning this matter (in the last one Linus even
> said, that he'll be accepting patches) and still I see no movement. I'd
> really like to see glibc guys figuring out a way not to duplicate definitions
> and structures from linux and starting to submit patches. That'd be a really
> good (and much needed - glibc's and linux' headers conflict in lots of ugly
> ways) first step.
> Anybody?

Yes, please don't give up. I'll try to help soon (not that I'm
a glibc guy).

> Happy New Year.

Ditto.

---
~Randy

Andrew Walrond

unread,
Jan 12, 2005, 5:50:37 AM1/12/05
to linux-...@vger.kernel.org, Mariusz Mazur
On Saturday 08 January 2005 15:13, Mariusz Mazur wrote:

Upgrading from 2.6.9.1 to 2.6.10.0 causes a mysql build failure on x86:

gcc -DDEFAULT_CHARSET_HOME=\"/pkg/mysql.1\" -DDATADIR=\"/pkg/mysql.1/state\"
-DSHAREDIR=\"/pkg/mysql.1/share/mysql\" -DDONT_USE_RAID -DMYSQL_CLIENT -fPIC
-I. -I. -I.. -I../include -O3 -DDBUG_OFF -march=i686 -O2 -MT password.lo -MD
-MP -MF .deps/password.Tpo -c password.c -fPIC -DPIC -o .libs/password.o
In file included from ../include/my_global.h:291,
from password.c:62:
/usr/include/asm/atomic.h: In function `atomic_add_return':
/usr/include/asm/atomic.h:189: error: `boot_cpu_data' undeclared (first use in
this function)

It builds fine on x86_64 though. I don't know where the fault lies here;
mysql, libc-headers or linux-2.6.10, so this is just a FYI.

Andrew Walrond

Mariusz Mazur

unread,
Jan 12, 2005, 6:14:18 AM1/12/05
to Andrew Walrond, linux-...@vger.kernel.org
On środa 12 styczeń 2005 11:49, Andrew Walrond wrote:
> Upgrading from 2.6.9.1 to 2.6.10.0 causes a mysql build failure on x8=
6:
>
> gcc -DDEFAULT_CHARSET_HOME=\"/pkg/mysql.1\"
> -DDATADIR=\"/pkg/mysql.1/state\" -DSHAREDIR=\"/pkg/mysql.1/share/=

mysql\"
> -DDONT_USE_RAID -DMYSQL_CLIENT -fPIC -I. -I. -I.. -I../include -O3
> -DDBUG_OFF -march=i686 -O2 -MT password.lo -MD -MP -MF .deps/passwo=
rd.Tpo

> -c password.c -fPIC -DPIC -o .libs/password.o In file included from
> ../include/my_global.h:291,
> from password.c:62:
> /usr/include/asm/atomic.h: In function `atomic_add_return':
> /usr/include/asm/atomic.h:189: error: `boot_cpu_data' undeclared (fir=

st use
> in this function)
>
> It builds fine on x86_64 though. I don't know where the fault lies he=
re;

> mysql, libc-headers or linux-2.6.10, so this is just a FYI.

Looks like you've linked your kernel's config.h to llh and that causes =
the
problem. You shouldn't do that unless you have a specific reason to,
otherwise you might end up with problems I'm unable to test for (I can'=
t
check every possible combination of kernel CONFIG_'s).

I'll state that more clearly in the docs.


--
In the year eighty five ten
God is gonna shake his mighty head
He'll either say,
"I'm pleased where man has been"
Or tear it down, and start again

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"=

Andrew Walrond

unread,
Jan 12, 2005, 7:05:49 AM1/12/05
to Mariusz Mazur, linux-...@vger.kernel.org
On Wednesday 12 January 2005 11:11, Mariusz Mazur wrote:
>
> Looks like you've linked your kernel's config.h to llh and that causes the

> problem. You shouldn't do that unless you have a specific reason to,
> otherwise you might end up with problems I'm unable to test for (I can't

> check every possible combination of kernel CONFIG_'s).
>

It seems that mysql looks for the existence of a compilable linux/config.h and
uses it if available. This has just happened to work until latest release of
llh. I had read your faq, but too long ago ;)

Thanks!

Andrew
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

Andrew Walrond

unread,
Jan 13, 2005, 3:17:23 AM1/13/05
to Mariusz Mazur, linux-...@vger.kernel.org
On Wednesday 12 January 2005 11:11, Mariusz Mazur wrote:
>
> Looks like you've linked your kernel's config.h to llh and that causes the

> problem. You shouldn't do that unless you have a specific reason to,
> otherwise you might end up with problems I'm unable to test for (I can't

> check every possible combination of kernel CONFIG_'s).
>

I know you are deliberately vague in the faq ;) But what about something like
X11? It needs the real config.h in order to build the kernel DRM drivers.
Should it be built against
1) llh + blank config.h
2) llh + real config.h
3) kernel source

I guess this ambiguity would go away once the real kernel headers have been
sanitized for userspace (ie we could always use the real config.h without
fear of breakage) But as you have already stated, the issues are complex, and
consensus is lacking. The longer the status quo continues, the more apps are
going to break when we do get round to it.

And I think, in this instance, the "shut up and hack" response is
inappropriate; Either these changes come from a senior linux hacker, or they
will be ignored/derided (again).

Andrew Walrond

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

Mariusz Mazur

unread,
Jan 13, 2005, 4:44:31 AM1/13/05
to Andrew Walrond, linux-...@vger.kernel.org
On czwartek 13 styczeń 2005 09:13, Andrew Walrond wrote:
> I know you are deliberately vague in the faq ;) But what about someth=
ing

> like X11? It needs the real config.h in order to build the kernel DRM
> drivers.

I'm a distribution vendor. If x11 really required having current kernel=
config
at compile time to function properly, I'd start sending threats to its
authors.

> Should it be built against
> 1) llh + blank config.h

Yes, if an app really does require config.h (and it *shouldn't*), it ou=
ght to
have the sanest possible default configuration (by default I mean witho=
ut
depending on any CONFIG_). And again that's something I can tell you as=
a
distro vendor.

> 2) llh + real config.h

And if you have some exotic configuration or such, and your app does su=
pport
it, then you should be using your kernel's config.h (though it would be=

preferable if you just added the appropriate CONFIG_s to otherwise empt=
y
config.h).

> 3) kernel source
>
> I guess this ambiguity would go away once the real kernel headers hav=
e been
> sanitized for userspace (ie we could always use the real config.h wit=
hout
> fear of breakage) But as you have already stated, the issues are comp=
lex,
> and consensus is lacking. The longer the status quo continues, the mo=
re


> apps are going to break when we do get round to it.
>
> And I think, in this instance, the "shut up and hack" response is

> inappropriate; Either these changes come from a senior linux hacker, =


or
> they will be ignored/derided (again).

--

In the year eighty five ten
God is gonna shake his mighty head
He'll either say,
"I'm pleased where man has been"
Or tear it down, and start again

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"=

Andrew Walrond

unread,
Jan 13, 2005, 6:23:05 AM1/13/05
to Mariusz Mazur, linux-...@vger.kernel.org
On Thursday 13 January 2005 09:42, Mariusz Mazur wrote:
>
> I'm a distribution vendor. If x11 really required having current kernel
> config at compile time to function properly, I'd start sending threats to
> its authors.

Well there is certainly stuff like

ifdef ARCHX86
ifndef CONFIG_X86_CMPXCHG
$(error CONFIG_X86_CMPXCHG needs to be enabled in the kernel)
endif
endif

and

ifdef CONFIG_AGP
ifneq (,$(findstring mga,$(DRM_MODULES)))
CONFIG_DRM_MGA := m
endif
endif

in x11, which makes me very nervous about a blank config.h.

Ho hum...

Andrew Walrond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

Rahul Karnik

unread,
Jan 13, 2005, 6:53:44 AM1/13/05
to Andrew Walrond, Mariusz Mazur, linux-...@vger.kernel.org
On Thu, 13 Jan 2005 11:00:19 +0000, Andrew Walrond <and...@walrond.org> wrote:
> On Thursday 13 January 2005 09:42, Mariusz Mazur wrote:
> >
> > I'm a distribution vendor. If x11 really required having current kernel
> > config at compile time to function properly, I'd start sending threats to
> > its authors.

We are not talking about an application, but rather out of tree kernel
modules (or rather, different versions of modules already in the
tree).



> Well there is certainly stuff like
>
> ifdef ARCHX86
> ifndef CONFIG_X86_CMPXCHG
> $(error CONFIG_X86_CMPXCHG needs to be enabled in the kernel)
> endif
> endif
>
> and
>
> ifdef CONFIG_AGP
> ifneq (,$(findstring mga,$(DRM_MODULES)))
> CONFIG_DRM_MGA := m
> endif
> endif

Let's be clear here: these are not regular X11 files, but those meant
to compile kernel modules. Are you surprised that config.h is needed?

-Rahul

Jakub Jelinek

unread,
Jan 13, 2005, 6:56:08 AM1/13/05
to Rahul Karnik, Andrew Walrond, Mariusz Mazur, linux-...@vger.kernel.org
On Thu, Jan 13, 2005 at 06:46:32AM -0500, Rahul Karnik wrote:
> We are not talking about an application, but rather out of tree kernel
> modules (or rather, different versions of modules already in the
> tree).

For kernel modules you should never use /usr/include headers though.
/lib/modules/`uname -r`/build/include headers should be used for them
instead.

Jakub

Andrew Walrond

unread,
Jan 13, 2005, 7:19:33 AM1/13/05
to linux-...@vger.kernel.org, Rahul Karnik, Mariusz Mazur
On Thursday 13 January 2005 11:46, Rahul Karnik wrote:
>
> Let's be clear here: these are not regular X11 files, but those meant
> to compile kernel modules. Are you surprised that config.h is needed?
>

Not at all. But different packages seem to have very different expectations of
what should be in <linux/config.h>...

As it stands, It would seem necessary to rewrite it to suit whichever package
I happen to need to build.

andrew@orac x11-XORG-6_8_1 $ grep -rF linux/config.h *
extras/drm/linux/i810_drv.c:#include <linux/config.h>
extras/drm/linux/ffb_drv.c:#include <linux/config.h>
extras/drm/linux/mga_drv.c:#include <linux/config.h>
extras/drm/linux/savage_drv.c:#include <linux/config.h>
extras/drm/linux/sis_drv.c:#include <linux/config.h>
extras/drm/linux/drm_memory.h:#include <linux/config.h>
extras/drm/linux/mach64_drv.c:#include <linux/config.h>
extras/drm/linux/gamma_drv.c:#include <linux/config.h>
extras/drm/linux/i830_drv.c:#include <linux/config.h>
extras/drm/linux/r128_drv.c:#include <linux/config.h>
extras/drm/linux/drm_scatter.h:#include <linux/config.h>
extras/drm/linux/radeon_drv.c:#include <linux/config.h>
extras/drm/linux/drm_memory_debug.h:#include <linux/config.h>
extras/drm/linux/drmP.h:#include <linux/config.h>
extras/drm/linux/tdfx_drv.c:#include <linux/config.h>
extras/drm/shared/via_drv.c:#include <linux/config.h>
extras/drm/shared/drm.h:#include <linux/config.h>
programs/Xserver/hw/xfree86/drivers/sis/osdef.h:#include <linux/config.h>
programs/Xserver/hw/xfree86/drivers/sis/init301.h:#include <linux/config.h>
programs/Xserver/hw/xfree86/drivers/sis/init.h:#include <linux/config.h>

Andrew Walrond

Rahul Karnik

unread,
Jan 13, 2005, 11:23:45 AM1/13/05
to Jakub Jelinek, Andrew Walrond, Mariusz Mazur, linux-...@vger.kernel.org
On Thu, 13 Jan 2005 06:51:54 -0500, Jakub Jelinek <ja...@redhat.com> wrote:
> On Thu, Jan 13, 2005 at 06:46:32AM -0500, Rahul Karnik wrote:
> > We are not talking about an application, but rather out of tree kernel
> > modules (or rather, different versions of modules already in the
> > tree).
>
> For kernel modules you should never use /usr/include headers though.
> /lib/modules/`uname -r`/build/include headers should be used for them
> instead.

I was replying to the following:

> On Thursday 13 January 2005 09:42, Mariusz Mazur wrote:
> > I'm a distribution vendor. If x11 really required having current kernel
> > config at compile time to function properly, I'd start sending threats to
> > its authors.

"current kernel config" is the the same as /lib/modules/`uname
-r`/build/include, isn't it? I was saying that kernel modules
absolutely require the headers for the running kernel, just as you
are. Granted, the drm makefiles may be broken anyway and point to
/usr/include/linux.

Thanks,
Rahul

Mariusz Mazur

unread,
Jan 13, 2005, 11:35:42 AM1/13/05
to Jakub Jelinek, Rahul Karnik, Andrew Walrond, linux-...@vger.kernel.org
On czwartek 13 styczeń 2005 12:51, Jakub Jelinek wrote:
> For kernel modules you should never use /usr/include headers though.
> /lib/modules/`uname -r`/build/include headers should be used for them
> instead.

Exactly (more or less - I don't always need to build against the kernel=
I'm
running - especially when building distro rpms).

*Any* sane userland application should avoid static dependencies on cur=
rent
kernel config *at* *all* *cost*.


--
In the year eighty five ten
God is gonna shake his mighty head
He'll either say,
"I'm pleased where man has been"
Or tear it down, and start again

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"=

Reply all
Reply to author
Forward
0 new messages