Re: SHA384_Update symbol clash with libgs

[Leonardo Taccari <leot%NetBSD.org@localhost>]

Greg Troxel writes:
> [...]
> In this case, though, it seems clear that libgs shouldn't use that name.
> I would suggest renaming it in the sources and APIs to gs_SHA384_Update,
> but I would suggest filing a bug upstream first to try to shed light on
> what's happening and why.
> [...]

I think that it was already addressed upstream (at least by inspecting
ghostscript-agpl ${WRKSRC}/doc/History9.htm):

 | [...]
 | 2013-11-11 12:41:02 +0000
 | [...]
 | 
 | Bug 694766: rename "internal" SHA symbols
 | 
 | Prevent linker errors when linking to something else that uses SHA,
 | by prepending "p" (for private) to our "internal" SHA symbols.
 | 
 | gs/base/sha2.c
 | gs/base/sha2.h
 | [...]

(and, at least an nm(1) against libgs.so of ghostscript-agpl reveals
that there are pSHA* symbols.)