[OE-core] Should disabling features in glibc also disable the corresponding headers?

Tanu Kaskinen tanu.kaskinen at linux.intel.com
Tue Apr 14 19:18:33 UTC 2015


On Tue, 2015-04-14 at 13:40 -0400, Khem Raj wrote:
> > On Apr 14, 2015, at 1:25 PM, Tanu Kaskinen <tanu.kaskinen at linux.intel.com> wrote:
> > 
> > Hello,
> > 
> > oe-core's version of glibc allows configuring out some libc
> features. Currently, if a feature is disabled in glibc, glibc still
> installs the header for that feature. This means that applications
> using glibc can't rely on checking just the header presence in their
> configure scripts, they also need to check whether the function
> implementation is present. Is there some good reason why glibc works
> that way, or should glibc be fixed so that disabling a feature
> disables the header too?
> > 
> > At least alsa-lib requires patching[1] for this reason, and I
> wouldn't be surprised if there were many other similar cases in other
> packages.
> > 
> > [1] http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-multimedia/alsa/alsa-lib/Check-if-wordexp-function-is-supported.patch
> > 
> 
> checking for functions is the right thing. And it would fail to link
> if you passed configure check.

Thanks for the quick reply. Could you elaborate why checking for
functions is the right thing? If that's the right thing, then I should
send that alsa-lib patch to upstream, and I want to be able to explain
why the patch is not a workaround for oe-core's glibc brokenness.

-- 
Tanu




More information about the Openembedded-core mailing list