On 15/12/14 14:16, Francisco Jerez wrote: > 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 :) >> >
Hi Francisco, Mostly a repeat from IRC for anyone interested: > I don't think the steam libstdc++ linking issue is a good argument > against adding a new dynamic dependency, If history has thought us anything (libudev, libgcc_s, libstdc++) having any extra dependencies will likely cause problems. > 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. > If they are doing something stupid, let us be the smarter one, and work things in such a way that despite how stupid it is it just works. I have mentioned three solutions below, yet there may be more. > 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. > Pick any library/project as you wish but consider the following: - Roll our own sha1/md5/etc. as already mentioned by OG and NR. Crypto security is not needed here but only a nice collision %. - Import the sources of project X. Sync it once every Y months and revert to the old as a contingency plan (be that a bug/problems updating etc.) - Provide a way to static link against library X, and if you insist a dynamic one. But before anything - put yourself in the shoes of the average linux user nowadays. I.e. eradicate some 80% of your knowledge. Now try to run steam (or any binary game/program) that ships its own libgcc_s/libstdc++. Cheers, Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev