bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
* strerror replacement problems on all BSDs
@ 2016-03-23 21:16 coypu
  2016-03-23 21:48 ` Eric Blake
  0 siblings, 1 reply; 3+ messages in thread
From: coypu @ 2016-03-23 21:16 UTC (permalink / raw
  To: bug-gnulib

Hello,
I've come across a problem with code using gnulib.

it attempts to replace strerror with strerror_rpl, resulting in errors
like the following:

undefined reference to `rpl_strerror'

https://lists.gnupg.org/pipermail/gnutls-devel/2013-November/006594.html

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.
You can see a list of those defined here:
http://nxr.netbsd.org/xref/src/sys/sys/errno.h

So while strerror is probably 'normal', gnulib chooses to replace it.

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

I do not understand the sed magic that follows, but it does not override
this definition.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: strerror replacement problems on all BSDs
  2016-03-23 21:16 strerror replacement problems on all BSDs coypu
@ 2016-03-23 21:48 ` Eric Blake
  2016-03-24 14:31   ` coypu
  0 siblings, 1 reply; 3+ messages in thread
From: Eric Blake @ 2016-03-23 21:48 UTC (permalink / raw
  To: coypu, bug-gnulib

[-- Attachment #1: Type: text/plain, Size: 1750 bytes --]

On 03/23/2016 03:16 PM, coypu@SDF.ORG 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?

> 
> it attempts to replace strerror with strerror_rpl, resulting in errors
> like the following:

Umm, you meant rpl_strerror.

> 
> 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.

> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: strerror replacement problems on all BSDs
  2016-03-23 21:48 ` Eric Blake
@ 2016-03-24 14:31   ` coypu
  0 siblings, 0 replies; 3+ messages in thread
From: coypu @ 2016-03-24 14:31 UTC (permalink / raw
  To: Eric Blake; +Cc: bug-gnulib

On Wed, Mar 23, 2016 at 03:48:00PM -0600, Eric Blake wrote:
> On 03/23/2016 03:16 PM, coypu@SDF.ORG 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.


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2016-03-24 14:31 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-03-23 21:16 strerror replacement problems on all BSDs coypu
2016-03-23 21:48 ` Eric Blake
2016-03-24 14:31   ` coypu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).