[Buildroot] glibc and --enable-kernel
Sam Bobroff
sam.bobroff at au1.ibm.com
Thu Jan 28 02:55:37 UTC 2016
On Wed, Jan 27, 2016 at 09:21:19AM +0100, Thomas Petazzoni wrote:
> Hello!
>
> On Wed, 27 Jan 2016 15:21:04 +1100, Sam Bobroff wrote:
>
> > I've noticed that when building glibc, buildroot's configure command doesn't
> > pass any "--enable-kernel" option, which according to the documentation...
> >
> > http://www.gnu.org/software/libc/manual/html_node/Configuring-and-compiling.html
> >
> > ... means that glibc is always built to support the oldest possible kernel.
> >
> > At first this seems like a good idea but the documentation is misleading, and
> > it actually causes two problems:
> >
> > 1) Unnecessary compat code: If you've built a kernel and glibc together
> > (presumably this is common when using buildroot) then you have no need of any
> > compat code because the only kernel you'll be using is the one you just built.
> > According to the doc (above) this causes glibc to include unnecessary compat
> > code which slows it down.
> >
> > 2) Availability of new features: It appears from the code that the
> > documentation leaves out some important information. What actually happens
> > while building glibc is that the "minimum kernel version" (which is either the
> > version given by "--enable-kernel=" or the oldest possible version for that
> > architecture) sets both __LINUX_KERNEL_VERSION and __ABI_TAG_VERSION so that
> > glibc will never use any kernel features *newer* than this version. Therefore
> > you cannot get access to recent kernel features *at all* via glibc (without
> > manually altering glibc.mk).
>
> Thanks a lot for spotting this problem and for the explanation,
> definitely makes sense.
>
> > (An example of a recent feature would be the sendmmsg syscall, which
> > requires a kernel version of 3.0.0 but the minimum version for PowerPC 64 is
> > 2.6.24.)
>
> Ah, so you're working on PowerPC 64, great! We have a toolchain build
> problem that I reported on Power PC 64, when building for Power 8:
>
> http://lists.busybox.net/pipermail/buildroot/2016-January/150338.html
>
> If you have some time to look at it, it would be great.
No problem, I've replied in that thread :-)
> > I'd like to prepare a patch to make this configurable, and it obviously
> > wouldn't be difficult to add but I'm not sure of the best way to do it.
> >
> > The most obvious way seems to be to add a menu item to the Toolchain menu, just
> > after "glibc version" (and only enabled when glibc is the C library), called
> > "glibc kernel API version" with a default value of "same as kernel headers".
> > The other options would be "as old as possible" or a specific version.
> >
> > Comments?
>
> I don't think you need to add additional options. We should just use
> the kernel version of the chosen kernel headers, since we're guaranteed
> that the running kernel will be at least more recent than the kernel
> headers being used.
>
> I.e, can you try something such as:
>
> --enable-kernel=$(call qstrip,$(BR2_TOOLCHAIN_HEADERS_AT_LEAST))
>
> BR2_TOOLCHAIN_HEADERS_AT_LEAST will be 3.0 if you use some 3.0.x kernel
> headers for your toolchain.
>
> Thanks!
Ok that is certainly easier and works for me, so I'll post a patch :-)
I'm curious tho: when I hacked up some test code I used
BR2_DEFAULT_KERNEL_HEADERS (which seems to have the same value) but I must
confess I don't understand the implications of choosing between
BR2_DEFAULT_KERNEL_HEADERS or BR2_TOOLCHAIN_HEADERS_AT_LEAST. Could you explain
the difference so I don't have to read so much Make code? ;-)
Cheers,
Sam.
More information about the buildroot
mailing list