[PATCH] Revert "Revert "Render: Use built-in SHA1 library""

[Yaakov (Cygwin/X)]

On 2010-04-12 11:22, Tiago Vignatti wrote:
> Once upon a time, back in 2007, Carl Worth was trying to boost render
> (4c6abe1c). He prefered to use a "strong hash" to compare glyphs (19b3b1fd)
> and used openssl library for this. Further, for the same purpose, people
> started to set other SHA1 implementations in autoconf. And a lot of
> alternatives appeared - six, to be precise. In the mean time, John Tapsell
> commit a builtin implementation of SHA1. In the same day, Keith Packard
> reverted, stating "X.org should not be providing a custom SHA1
> implementation." (a39377cb). Now, users ended up with Xorg setting the default
> as the openssl's one (libcrypto), which takes 88 kB of xserver's private RSS.
> Besides that, we have a ridiculous "configure dot [...] ac stanza to work
> out which lib to use is almost as long as sha1.c was", to quote daniels.
>
> My simple argument against Keith's decision is simple: we can save 316 kB of
> RSS in a standalone Xorg call. Therefore, I'm in favor to keep our own very
> simple and shiny SHA1 implementation.

Nack.

Those platforms that use their own system libraries (libc, libmd, 
CommonCrypto) probably don't want to use static code, especially if 
their versions are optimized.  As for Linux, the major distros don't 
seem to ship either libmd or libsha1 (and libmd doesn't use libtool so 
it's not very portable for e.g. Cygwin OOTB), so they will end up using 
libgcrypt or openssl.

The libsha1 detection should probably be moved up to before libgcrypt, 
but otherwise I think the current situation makes sense, that we go from 
builtin implementations, to smallest/fastest to largest.


Yaakov
Cygwin/X