[ANNOUNCE] linux-libc-headers 2.6.10.0

[ANNOUNCE] linux-libc-headers 2.6.10.0

[Mariusz Mazur]

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

Re: [ANNOUNCE] linux-libc-headers 2.6.10.0

[Randy.Dunlap]

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

Re: [ANNOUNCE] linux-libc-headers 2.6.10.0

[Andrew Walrond]

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

Re: [ANNOUNCE] linux-libc-headers 2.6.10.0

[Mariusz Mazur]

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

Re: [ANNOUNCE] linux-libc-headers 2.6.10.0

[Andrew Walrond]

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

Re: [ANNOUNCE] linux-libc-headers 2.6.10.0

[Andrew Walrond]

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

Re: [ANNOUNCE] linux-libc-headers 2.6.10.0

[Mariusz Mazur]

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

Re: [ANNOUNCE] linux-libc-headers 2.6.10.0

[Andrew Walrond]

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

Re: [ANNOUNCE] linux-libc-headers 2.6.10.0

[Rahul Karnik]

On Thu, 13 Jan 2005 11:00:19 +0000, Andrew Walrond <andrew@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

Re: [ANNOUNCE] linux-libc-headers 2.6.10.0

[Jakub Jelinek]

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

Re: [ANNOUNCE] linux-libc-headers 2.6.10.0

[Andrew Walrond]

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

Re: [ANNOUNCE] linux-libc-headers 2.6.10.0

[Rahul Karnik]

On Thu, 13 Jan 2005 06:51:54 -0500, Jakub Jelinek <jakub@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

Re: [ANNOUNCE] linux-libc-headers 2.6.10.0

[Mariusz Mazur]

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