On Fri, Dec 12 2014, Jose Fonseca wrote: > Yes, ideally we'd have something small that we could bundle into mesa > source tree, for sake of non Linux OSes.
Ken has pointed to an implementation that might be suitable for this. I haven't reviewed that code myself, nor am I signing up to maintain a SHA-1 implementation within Mesa. But if somebody does want to do that review and maintenance, then it would be a very simple extension of the code I've provided to allow a builtin implementation as well as all of the external implementations that are deteted. > If Windows was the only concern, we could use its Crypto API, > http://msdn.microsoft.com/en-us/library/windows/desktop/aa382379.aspx > and avoid depending on anything else, but some of the above mention > libraries are not trivial to install. I believe that the second patch I posted, (as well as what I'm about to follow up with), does have support for CryptoAPI. Would you be available to test that? > The other alternative is to disable shader cache when no suitable > dependency is found. That is, make this an optional dependency. That makes a lot of sense and should make this feature quite non-controversial, since it doesn't force any new dependency requirement on anyone who can't easily satisfy it. I've now written the configure machinery to do exactly this. I've also tested, (and fixed), the code I posted earlier to detect and choose from among several different SHA-1 implementations. Specifically, I've tested that it works correctly with --with-sha1=libnettle, --with-sha1=libgcrypt, or --with-sha1=libcrypto, (three libraries that I happened to have installed). I haven't tested the others, but I'm optimistic that they should work unchanged from the xserver implementation. I'll follow to this email with my two latest patches. -Carl
pgpFekw9JDxhc.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev