Re: strerror vs. threads

[Paul Eggert]

Having had to deal with too many dependencies when using gnulib
in GNU Emacs, I can sympathize with Sam Steingold: it'd be nicer
to not pull in lock.c, lock.h, threadlib.c merely because an
application wants to use strerror.  For example, I can't see Emacs using
the strerror module if this problem isn't addressed.

Eric already pointed out that this locking is only needed for
multithreaded apps.  Also, it strikes me that most applications don't
care whether perror modifies the strerror static buffer, and
if that's the reason behind this change, then
applications that don't care about this bug shouldn't need
to pull in strerror_r, much less the locking code.

Fixing this dependency creep will require some work and testing,
and that's not always trivial to do.  I hope someone (Sam, maybe?)
can help out with that.