imporomper initialization breaks compilation on Solaris #876
Conversation
greghudson
force-pushed
the
init.array
branch
from
bf28c90
to
70bdea2
Compare
|
I squashed in #877, #880, and #881 and made some minor changes. Please check if the revised commit works for you. I'm not philosophically opposed to an autoconf test for __int128_t support. I was trying to adhere closely to the BoringSSL code, but they have different portability requirements. The other half of that test is whether the platform is 64-bit. (Otherwise I believe it's more efficient to use the 32-bit code even if the compiler supports a 128-bit type.) I guess that's easily determined with |
this still works. I'm happy with squashing all those pull requests to single changeset. And also thank you for making my changes to look better, especially
OK I'll try to cook something up and we will see if it will be a good fit or not. FYI: the test failure I've mentioned in #880, covered my back. I've messed up |
|
Do the autoconf tests in this updated commit work for you? |
yes, I need to run |
In the LDAP KDB module, fix an empty initializer. In the SPAKE edwards25519 code, use autoconf tests to determine whether to use the 64-bit code. In the SPAKE update_thash() function, make sure the types of the conditional expression results match exactly. In libkrb5support, link against zap.o now that k5buf.o can use zap() (as of commit 8ee8246). [ghudson@mit.edu: squashed commits; rewrote commit message; adjusted autoconf tests; minor code changes] ticket: 8769 (new) tags: pullup target_version: 1.17
gcc we use on Solaris complains about empty initialization. This small patch
makes it happy.
I gave a try to krb5-1.17-beta2