The current test only checks whether ld64 is available, causing tests
to fail when ld64 is avilable but libLTO is not built.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Is there an LLVM config option that allows to run make check and not have libLTO built?
-DLLVM_TOOL_LTO_BUILD=OFF.
The background here is that I have an unfortunate bot with an old XCode toolchain, with an ld64 (ld64-236.4) that apparently does not support the -lto_library flag. So when the tests run it tries to use its libLTO (based on llvm 3.4) instead of the just-built libLTO, and it's of course unable to read the bitcode under test. So I thought of using -DLLVM_TOOL_LTO_BUILD=OFF which works, except that the tests still run.
An alternative to checking for the existence of the file is to change llvm/test/lit.site.cfg.in to add to the config the value of LLVM_TOOL_LTO_BUILD, and it would be available directly here.
I don't mind doing it either way; I just noticed that have_ld_plugin_support() does the same thing (checking for the existence of the DSO). Should I switch both of them?
Let see what @beanz thinks. I have a mild preference to use the CMake variable, since in general it is easy to mess up checking the right path and silently disable tests. The CMake variable shields a user from "accidentally" disabling the tests.
That's a good point, and I also just realized that libLTO builds on Linux too, so the 'dylib' extension is a nonstarter. I'll go with the alternative.
I realized that the gold part of this change was wrong, so I took that part out and landed just the libLTO part for now.
I also am now having second thoughts that the gold part of the change is good, because the condition for whether the gold plugin gets built is nontrivial (it's LLVM_ENABLE_PIC and LLVM_BINUTILS_INCDIR and implicitly LLVM_TOOL_GOLD_BUILD). So maybe just testing for the presence of the DSO is less error-prone than duplicating that logic in the lit file.
Yeah, without a straightforward cmake way of detecting it, it is likely better this way!