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
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
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
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 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.
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
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
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
On czwartek 13 stycze? 2005 09:13, Andrew Walrond wrote:
> 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.
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 ought to
have the sanest possible default configuration (by default I mean without
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 support
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 empty
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).
--
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
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
On Thu, 13 Jan 2005 11:00:19 +0000, Andrew Walrond <[email protected]> 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
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
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
On Thu, 13 Jan 2005 06:51:54 -0500, Jakub Jelinek <[email protected]> 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
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 current
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