bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: strerror replacement problems on all BSDs


From: coypu
Subject: Re: strerror replacement problems on all BSDs
Date: Thu, 24 Mar 2016 14:31:06 +0000
User-agent: Mutt/1.5.23 (2014-03-12)

On Wed, Mar 23, 2016 at 03:48:00PM -0600, Eric Blake wrote:
> On 03/23/2016 03:16 PM, address@hidden wrote:
> > Hello,
> > I've come across a problem with code using gnulib.
> 
> We'll need a bit more context: what program are you trying to build, and
> what gnulib commit is it using?
> 

I was running the testsuite of GnuTLS-3.4.10. It is the latest version.
> > 
> > it attempts to replace strerror with strerror_rpl, resulting in errors
> > like the following:
> 
> Umm, you meant rpl_strerror.
> 

Sorry about that.
> > 
> > undefined reference to `rpl_strerror'
> > 
> > https://lists.gnupg.org/pipermail/gnutls-devel/2013-November/006594.html
> 
> That's a very old message.  Is it still occurring in modern gnutls?  Has
> gnutls updated to modern gnulib?  Most likely, the bug is in gnutls, not
> gnulib.
> 
> > 
> > This occurs for two reasons:
> > 
> > Problem #1:
> > m4/strerror.m4:56-96
> > 
> > this tests for strerror(0).
> > 
> > NetBSD (and likely other *BSDs) do not define errno 0.
> 
> No one defines errno 0.  But POSIX has specific requirements on how
> strerror(0) is supposed to behave, and gnulib is correctly detecting
> that the strerror() on NetBSD is not (yet) compliant with those
> requirements.
> 

All right, I agree that from gnulib's perspective, it seems broken.
If it interests you, someone has requested this change already in
NetBSD.
> > Problem #2:
> > lib/string.in.h:958-959
> > #   undef strerror
> > #   define strerror rpl_strerror
> > 
> > it redefines strerror as rpl_strerror, but then does not proceed to
> > define rpl_strerror
> 
> rpl_strerror is defined in lib/strerror.c, and gnulib sets up the
> makefile so that strerror.o gets linked in (and thus provides
> rpl_strerror) if the defines in string.in.h were triggered via sed magic
> to state that strerror was defective and needs replacing.  It works fine
> in other projects, so I'd need more context why it does not seem to be
> working in the manner that gnutls is using it.
> 
> -- 
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
> 

I've tried my best to look, but I am not knowledgeable enough to figure
out what is wrong, even given this information.

At least, it seems like using GNU sed instead is not changing matters,

GnuTLS has been resolving their problem with #undef strerror whenever
they wish to use it. You can see this in lib/nettle/egd.c,
lib/nettle/rnd-common.c.
Removing it generates build problems.

Sorry about not having a simple test case.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]