Should disabling features in glibc also disable the corresponding headers?

Should disabling features in glibc also disable the corresponding headers?

[Tanu Kaskinen]

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

-- 
Tanu

Re: Should disabling features in glibc also disable the corresponding headers?

[Khem Raj]

> On Apr 14, 2015, at 1:25 PM, Tanu Kaskinen <tanu.kaskinen@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.

> -- 
> Tanu

Re: Should disabling features in glibc also disable the corresponding headers?

[Tanu Kaskinen]

On Tue, 2015-04-14 at 13:40 -0400, Khem Raj wrote:
> > On Apr 14, 2015, at 1:25 PM, Tanu Kaskinen <tanu.kaskinen@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