Hi.
I am currently trying to rebuild a recent version of fwbuilder for Fedora Extras and I have hit a wall.
The wall is named ns_parserr() and it comes from libresolve, which exists in a static and a dynamic form in /usr/lib. Both seem to be unusable for this function.
ns_parserr is replaced by __ns_parserr by the preprocessor. The latter symbol is not present in -lresolv. It is provided, though, by libresolv.a, which fwbuilder thus chooses to link against. This introduces a GLIBC_PRIVATE symbol into the binary (__res_iclose) which RPM does not like at all.
So what am I supposed to do against this? Should ns_parserr not be used? Is there a bug in glibc?
Ralf Ertzinger wrote:
So what am I supposed to do against this? Should ns_parserr not be used?
Correct. Every symbol which is not exported from the DSOs or exported with version GLIBC_PRIVATE are, shockingly, *private*. They might go away, their semantics can change, whatever. There is no way to prevent such exports from .a files so they are available there but this does not mean they should be used.
On Mon, Dec 19, 2005 at 07:24:18AM -0800, Ulrich Drepper wrote:
Correct. Every symbol which is not exported from the DSOs or exported with version GLIBC_PRIVATE are, shockingly, *private*.
But ns_parserr is not private. It is defined if you include <resolv.h>.
away, their semantics can change, whatever. There is no way to prevent such exports from .a files so they are available there but this does not mean they should be used.
Any suggestions as what the official replacement for ns_parserr is?
Ralf Ertzinger wrote:
But ns_parserr is not private. It is defined if you include <resolv.h>.
The header content is irrelevant when it comes to deciding what is private or not.
Any suggestions as what the official replacement for ns_parserr is?
Write it on your own? Lift it from BIND?