I think I may have found the issue. Not sure if other architectures could be affected.
Looking at the cmake build artifacts under the "Build" directory, there are several instances of "feature_tests.c" and "feature_tests.cxx" with "const char features[]" initialized to '{ "" ... }' where I'm reasonably certain the intent is for the first byte of the "features" array to be a NULL. When "strings" is run on the resulting ".bin" file to extract the tokens of interest, there's no leading NULL byte in front of what is supposed to be the first non-NULL character in "features": that's where the mysterious leading "k" is coming from, and why only the first token in the array is "corrupted" in that manner. In other words, whichever feature appears first in the "const char features[]" array is going to be the one flagged as not supported. Replacing "" with "\0" correctly produces the intended NULL byte at the start of the array, and ultimately allows a working "cmake" to be built on Alpha. The question then is whether "" is supposed to compile to a NULL byte in the context of the "const char features[]" array, and whether this compiler behavior applies to other architectures. My fear is that we're simply getting lucky on x86, and any NULL in front of the array is there by accident. Not sure where/how to apply a proper fix. --Bob