[Top][All Lists]

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

Re: strerror replacement problems on all BSDs

From: Eric Blake
Subject: Re: strerror replacement problems on all BSDs
Date: Wed, 23 Mar 2016 15:48:00 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

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?

> 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

> 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

> 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: signature.asc
Description: OpenPGP digital signature

reply via email to

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