https://bugs.winehq.org/show_bug.cgi?id=46471
--- Comment #7 from noabody@yahoo.com --- Which still doesn't explain why it works in wine-stable on the exact same prefix.
Clearly gnutls is throwing the divide by zero in staging but what component is making a function call to divide by zero? I suppose I'll have to figure out valgrind to get more information.
I recently notified mono-project they were rolling out a distribution that requires sse4.1, in their AOT "Ahead Of Time", per-machine, compiler optimization. They said it was an issue with LLVM and added a check to only run AOT via LLVM if sse4.1 is available.
That said, mono can launch Keepass and the database decrypts without a problem. All of this is mounting evidence that rules out gnutls as the source in so far as it divides by zero because it's being asked to divide by zero. To take it one step further, I built both nettle and gnutls locally then took libgnutls.so.30 and libnettle.so.6 and put them in the LD_LIBRARY= path.
GNUTLS_CPUID_OVERRIDE=0x1 GNUTLS_DEBUG_LEVEL=9 LD_LIBRARY_PATH=$HOME/.local/lib wine KeePass.exe
Still divide by zero. I'm confident that the flagged libraries are not optimized for SSSE3 because, if they were, my machine would be incapable of compiling them successfully. I had already built wine staging locally and it still had the same problem.
I do appreciate the help, and have spent a great deal of time troubleshooting this problem on my own. The weight of that doesn't suggest a problem with ancillary libraries but something in wine-staging.
What I believe I'm hearing is that current versions of wine not longer stub functions that are optimized for SSSE3 by dotnet/mono and possibly keepass (since it has a history of its own). That mono itself will not work with AMD K10 architecture. That's just writing on the wall, though.
The K10 is unquestionably a serviceable architecture for general purpose work. It's the last vestige of early multi-core 64-bit architecture. Single-core 32-bit non-sse2 went into disuse some time ago.