Cannot find source file: TestPrograms/test_x86_sse2.cxx

[kychancf]

MacOS Catalina, CLion 2020.3 Build #CL-203.5981.166, built on December 2, 2020.

I simply include the CMakeList.txt provided in my project. Then, the "Cannot find source file" comes out. However, I checked the file exist.

May I ask how to deal with this issue?

Thank you very much!

====================[ Build | secretsharing | Debug ]===========================
/Applications/CLion.app/Contents/bin/cmake/mac/bin/cmake --build /Users/<my user name>/CLionProjects/secretsharing/cmake-build-debug --target secretsharing -- -j 6
-- *************************************************************************
The Crypto++ library does not officially support CMake. CMake support is a
community effort, and the library works with the folks using CMake to help
improve it. If you find an issue then please fix it or report it at
https://github.com/noloader/cryptopp-cmake.
-- *************************************************************************
-- CMake version 3.17.3
-- Performing Test CRYPTOPP_IA32_SSE2
CMake Error at /Users/<my user name>/CLionProjects/secretsharing/cmake-build-debug/CMakeFiles/CMakeTmp/CMakeLists.txt:14 (add_executable):
  Cannot find source file:

    /Users/<my user name>/CLionProjects/secretsharing/TestPrograms/test_x86_sse2.cxx

  Tried extensions .c .C .c++ .cc .cpp .cxx .cu .m .M .mm .h .hh .h++ .hm
  .hpp .hxx .in .txx

CMake Error at /Users/<my user name>/CLionProjects/secretsharing/cmake-build-debug/CMakeFiles/CMakeTmp/CMakeLists.txt:14 (add_executable):
  No SOURCES given to target: cmTC_581a2

CMake Error at cryptopp/CMakeLists.txt:246 (try_compile):
  Failed to generate test project build system.
Call Stack (most recent call first):
  cryptopp/CMakeLists.txt:551 (CheckCompileLinkOption)
  CMakeLists.txt:6 (include)

-- Configuring incomplete, errors occurred!
See also "/Users/<my user name>/CLionProjects/secretsharing/cmake-build-debug/CMakeFiles/CMakeOutput.log".
make: *** [cmake_check_build_system] Error 1

[smessmer]

I'm seeing the same issue but for a different .cxx file, see https://pastebin.com/2rgJttJE.

I noticed that .cxx files are listed in the .gitignore? So I assume the build process is somehow supposed to generate them?

Also note that I was building CryptoP++ 8.4 but using the CMake file for Crypto++ 8.3 because there's no 8.4 release for the CMake file yet.

[smessmer]

My setup worked with cryptopp 8.2 but breaks when going to 8.4. Does this maybe have something to do with the new configure.sh script from https://github.com/weidai11/cryptopp/issues/950 ? I didn't add any call to a configure script, trusting that cryptopp-cmake would call it for me.

[smessmer]

@noloader any ideas? Is this maybe because the CMakeFiles.txt for CryptoPP 8.4 isn't released yet?

[smessmer]

This is still happening for CryptoPP 8.5 with the correct cryptopp-cmake for 8.5

[noloader]

I'm not seeing this issue on Travis or AppVeyor. Those are my testing forks when CMake is tested.

Maybe you have a different directory structure. The tests in my CI's are performed with CmakeList.txt in the same directory as Crypto++ source files.

[smessmer]

It finds the directory correctly, but when I look into it, there's only these files in there:

test_32bit.cxx        test_arm_asimd.cxx    test_arm_pmull.cxx    test_arm_sm3.cxx      test_newlib.cxx       test_ppc_power7.cxx   test_ppc_sha.cxx      test_x86_aes.cxx      test_x86_avx512.cxx   test_x86_sha.cxx      test_x86_sse41.cxx    
test_64bit.cxx        test_arm_crc.cxx      test_arm_sha3.cxx     test_arm_sm4.cxx      test_ppc_aes.cxx      test_ppc_power8.cxx   test_ppc_vmull.cxx    test_x86_avx.cxx      test_x86_clmul.cxx    test_x86_sse2.cxx     test_x86_sse42.cxx    
test_arm_aes.cxx      test_arm_neon.cxx     test_arm_sha512.cxx   test_cxx.cxx          test_ppc_altivec.cxx  test_ppc_power9.cxx   test_pthreads.cxx     test_x86_avx2.cxx     test_x86_cpuid.cxx    test_x86_sse3.cxx     test_x86_ssse3.cxx 

The file test_mixed_asm.cxx it is complaining about is actually missing.

On some machines, the build succeeds for me too, it only fails on others and I haven't figured out yet what the difference between the machines is. One thing to note is that on the machines where the build succeeds, there is a file test_asm_mixed.cxx in the TestPrograms directory but also no test_mixed_asm.cxx. But this doesn't seem to bother cmake on those machines. The machines where the build fails and where it complains about a missing test_mixed_asm.cxx has neither of those files after a cmake run.

edit: Looking at the code in https://github.com/noloader/cryptopp-cmake/blob/master/CMakeLists.txt#L569 , this kind of makes sense. If it finds a test_asm_mixed.cxx, it uses that one and doesn't check for test_mixed_asm.cxx. But I didn't find the location where those files are supposed to be generated. .cxx files are listed in the .gitignore, so they're not in the repository and must be generated somehow. Could you point me to where?

[noloader]

You are mixing and matching versions of Crypto++ and CMake. Both are released at the same time to avoid these kinds of breaks.

You have two choices. First, you can use the same version of each released ZIP file.

Second, you can fetch the missing file from https://github.com/weidai11/cryptopp/tree/master/TestPrograms.

[smessmer]

No, I'm not mixing and matching, I am using the cmake for Crypto++ 8.5 with Crypto++ 8.5.

But I found out what the issue was, it's an issue in the main crypto++ repository. *.cxx is in the .gitignore but at the same time there are those *.cxx files in the repository. Now when I copy over the crypto++ project into a subdirectory of my own project, the .gitignore will prevent those .cxx files from being checked in and they'll be missing in my copy of the project.

It might make sense to remove .cxx from the .gitignore since this seems to be a mistake that is very easy to make if you use crypto++ in a subdirectory of your own project.

This is the .gitignore entry I'm talking about: https://github.com/weidai11/cryptopp/blob/master/.gitignore#L6

Thanks for your help in tracking this down :)