Emil Velikov <emil.l.veli...@gmail.com> writes: > On 11/12/14 21:51, Carl Worth wrote: >> From: Kristian Høgsberg <k...@bitplanet.net> >> >> The upcoming shader cache uses the SHA-1 algorithm for cryptographic >> naming. These new mesa_sha1 functions are implemented with the nettle >> library. >> --- >> >> This patch is another in support of my upcoming shader-cache work. Thanks to >> Kritian for coding this piece. >> >> As currently written, this patch introduces a new dependency of Mesa on the >> Nettle library to implement SHA-1. I'm open to recommendations if people >> would prefer some other option. >> >> For example, the xserver can be configured to get a SHA-1 implementation from >> libmd, libc, CommonCrypto, CryptoAPI, libnettle, libgcrypt, libsha1, or >> openssl. >> >> I don't know if it's important to offer as many options as that, which is why >> I'm asking for opinions here. >> > Hi Carl, > > Can we try to avoid adding new dependencies to mesa unless absolutely > needed. Neither of the proprietary drivers does so presently, so it will > be nice to keep the trend. > > While currently the steam runtime does not include libnettle I can > envision one day that they will/might. Even with steam aside I think > that this might cause issues with gnome & others' sandboxing. > > Long story short - can we import a sha1 implementation from another > project ? It will save us the "libstdc++ style steam runtime" issues, > plus it will ease the question of what to do under Windows :) >
I don't think the steam libstdc++ linking issue is a good argument against adding a new dynamic dependency, AFAICT that one's caused by the steam run-time being stupid trying to override the system libstdc++.so/libgcc_s.so with its own outdated versions even though the GCC C++ runtime has done a good job in the past at keeping binary compatibility across different releases with the same major number through library, symbol and namespace versioning. I'm OK with adding a dependency on libnettle, and I think that dynamic linking is preferrable to static linking if the library we end up depending on follows reasonable versioning practices. > > Thanks > Emil > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
pgpHiyByRqb_m.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
