On 15/12/14 17:19, Matt Turner wrote: > On Mon, Dec 15, 2014 at 3:15 AM, Emil Velikov <emil.l.veli...@gmail.com> > wrote: >> On 14/12/14 17:19, Matt Turner wrote: >>> On Sun, Dec 14, 2014 at 7:06 AM, Emil Velikov <emil.l.veli...@gmail.com> >>> wrote: >>>> 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 :) >>> >>> It's working okay for the xserver, isn't it? >>> >> The xserver is linking against libudev and we all know how nicely that >> one went. > > Sorry, I don't actually. > Check out commit 4556c734700(loader: Use dlsym to get our udev symbols instead of explicit linking.) or 63546b8e3d2(dri: Also support the loader with libudev.so.0.) and their relevant bug reports.
Hope that you're aware about the libgcc_s/libstdc++ issue. If not check out [1] or just google "steam+linux+libstdc++". You'll find dozens of reports. >> Here are the libs that we're missing wrt xserver: >> NEEDED libdbus-1.so.3 >> NEEDED libudev.so.1 >> NEEDED libgcrypt.so.20 >> NEEDED libpciaccess.so.0 >> NEEDED libpixman-1.so.0 >> NEEDED libXfont.so.1 >> NEEDED libXau.so.6 >> NEEDED libsystemd.so.0 >> NEEDED libxshmfence.so.1 >> NEEDED libXdmcp.so.6 >> >> >> Imho going for a "having as little external dependencies as possible" >> sounds better than "how many can we stuff in and get away with". >> Admittedly those are extraditions yet they nicely indicate the opposing >> directions. > > This sounds like a false dilemma. > > Let's try doing what the xserver does as a first approximation and if > we discover problems we can revisit. > Going with that assumption is known to not be the best of ideas. Why do you insist on repeating it, is what worries me. Cheers, Emil [1] https://wiki.archlinux.org/index.php/Steam#Steam_runtime_issues _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
