I’ve been working on a set of Python build scripts to build a baremetal Cortex-M toolchain, which you can see here on GitHub. It does a two-stage build using the CMake cache files in the “cmake_caches” directory in that repo. They are based on the cache file examples in “llvm/clang/cmake/caches”. I have the second stage set to build for the host (because LLVM-libc needs this), Mips, and ARM.
I can build a full toolchain on Linux (well, WSL), but on Windows I get the following error during the second stage of the two-stage build:
I don’t know what SandboxIR is or if I can choose to not build it. This does not show up when building with WSL. This does seem to be a known issue because the documentation for APInt has this.
/// Equivalent to APInt(numBits, ArrayRef<uint64_t>(bigVal, numWords)), but
/// deprecated because this constructor is prone to ambiguity with the
/// APInt(unsigned, uint64_t, bool) constructor.
///
/// If this overload is ever deleted, care should be taken to prevent calls
/// from being incorrectly captured by the APInt(unsigned, uint64_t, bool)
/// constructor.
APInt(unsigned numBits, unsigned numWords, const uint64_t bigVal[]);
I had a look myself but I don’t know A: why the compiler thinks this and B: how to annotate this to avoid it. Perhaps another equivalent but less ambiguous constructor could be used?
I just grabbed the head of the main branch and ended up with commit “52317363”. I’m doing a two-stage build. I build stage one with the VS 2022 Build Tools and the error occurs with the just-built clang in stage two.I’ll give that older version a shot since I don’t really need the absolute latest in main. This might explain why I didn’t see the issue in WSL; I certainly have an older version there by at least a couple of weeks. I did try looking at the commit history for a few files to see I could see anything that might clue me into what was going on, but I don’t know enough about a lot of LLVM to properly judge that.
I can give that patch a try, though I’ve run into another problem. I’ll mention it here in case I’m still having this issue with the more updated patched version.
I tried the commit previous to the one in DavidSpickett’s post and now I’m having issues with whatever a “resource compiler” is. I think it’s getting further than before, but I get this error now. Running that rc.exe file manually with the same parameters results in the same error.
Looking online, all I could find is that error RC1109 means that the location might be read-only? It’s hard to tell because apparently the “Read-only” attribute of folders is always partially filled in on Windows and clearing that didn’t help anyway. I’m not sure this makes sense since if the location were truly read-only then I would think the build wouldn’t work at all.
Using your updated patch gets me to the same spot with the confusing rc.exe error, so I’m guessing your patch did the trick. I still don’t know what the deal is with this RC1109 error.
EDIT: I must have ended up with a path that was too long because moving the build script to a shallower directory fixed the rc.exe problem. I was able to build Clang and run the check-llvm tests, so your patch worked! Thanks!