src/common/crc32c_ppc_asm.s ppc64le build break
It looks like there is a build break on ppc64le architecture associated with a recent change. The error message looks like this ...
[ 51%] ?[32mBuilding ASM object src/CMakeFiles/common-objs.dir/common/crc32c_ppc_asm.s.o?[0m
/home/ubuntu/ceph/kestrels.1/ceph/src/common/crc32c_ppc_asm.s: Assembler messages:
/home/ubuntu/ceph/kestrels.1/ceph/src/common/crc32c_ppc_asm.s:84: Error: unrecognized opcode: `func_start(__crc32_vpmsum)'
/home/ubuntu/ceph/kestrels.1/ceph/src/common/crc32c_ppc_asm.s:127: Error: unrecognized opcode: `mtvrd(v8,'
/home/ubuntu/ceph/kestrels.1/ceph/src/common/crc32c_ppc_asm.s:200: Error: unrecognized opcode: `vperm(v16,v16,v16,byteswap)'
/home/ubuntu/ceph/kestrels.1/ceph/src/common/crc32c_ppc_asm.s:201: Error: unrecognized opcode: `vperm(v17,v17,v17,byteswap)'
This occurs because someone renamed the file src/common/crc32c_ppc_asm.S to .s and now gcc doesn't accept that as an assembly file.
git log --follow -p crc32c_ppc_asm.s | pg
Author: Bassam Tabbara <firstname.lastname@example.org>
Date: Wed May 17 17:41:16 2017 -0700
cmake: workaound ccache issue with .S assembly files
when building with -DWITH_CCACHE=ON recent versions of ccache
(for example 3.3.3) seem to mangle object files from the cache
for source files that have a .S extension. This seems similar
but unrelated to PR #14633. The workaround here is to rename .S
files to .s (lower case).
Signed-off-by: Bassam Tabbara <email@example.com>
Here is the url for the merge of the above commit:
Here is the url for the pull request of the above commit:
#1 Updated by Andrew Solomon over 3 years ago
I believe the original issue was specific to intel / yasm and had nothing to do with ppc64le. The ppc64le assembly file was simply changed to maintain symmetry (ie a cosmetic reason, not a functional one).
I'm currently testing the fix, which would be to rename src/common/crc32c_ppc_asm.s to .S (and change the corresponding name in src/CMakeLists.txt).
#3 Updated by Nathan Cutler over 3 years ago
Hi. I'm working on this issue, too - see #20106
So far I have determined that merely renaming crc32_ppc_asm.s to crc32_ppc_asm.sx does not fix the issue. The build still fails, though in a different way.
Completely reverting PR#15142 does fix the issue. I'm still not sure why, though.