Should disabling features in glibc also disable the corresponding headers?
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.
Signature · 1 line
Tanu
Quoted 11 lines · 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.
checking for functions is the right thing. And it would fail to link if you passed configure check.
Quoted 2 lines
Signature · 1 line
Tanu
Quoted 14 lines · Khem Raj
Quoted 5 lines · 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?
Quoted 2 lines
At least alsa-lib requires patching[1] for this reason, and I
Quoted 8 lines
wouldn't be surprised if there were many other similar cases in other packages.
Quoted 3 lines
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.
Signature · 1 line
Tanu