search

SNSystems / llvm-project-prepo

Fork of LLVM with modifications to support a program repository
26 stars 0 forks source link

Docker build fails #129

Closed paulhuggett closed 3 years ago

paulhuggett commented 4 years ago

Running the top-level helper script:

cd llvm/utils/repo/docker
./build.sh

The error is:

CMake Error at /tmp/workspace/build/lib/FuzzMutate/cmake_install.cmake:41 (file):
  file INSTALL cannot find "/tmp/workspace/build/lib/libLLVMFuzzMutate.a".
Call Stack (most recent call first):
  /tmp/workspace/build/lib/cmake_install.cmake:43 (include)
  /tmp/workspace/build/cmake_install.cmake:65 (include)

Synched to commits c2a0a156246acfb577c6c8f0820d2c1b4ba20d5b SNSystems/pstore@ee6daee3a8790e81f4dd4597d32c93f50702226a.

It looks like someone reported a similar problem to llvm-dev at the end of August which received no reply. Did something break on the last update from upstream?

paulhuggett commented 4 years ago

Did something break on the last update from upstream?

Yes, it looks as though it did. The build succeeds at commits b2169ac8e96fb429ea8ab29d095b13fd61d9a44d and SNSystems/pstore@d7ad8bed3a26ab625d3c38dbfa778cbfe2d46389. This was (I think) just before the upstream merge (commit 0c369da5ccc95e7108594217269531b2ac73819d).Something in one of the 38,377 changed files likely introduced the problem…

paulhuggett commented 3 years ago

Yes, it looks as though it did.

There may be more to it than this. The problem doesn’t occur if I remove pstore from the list of components to be install. My working theory is that installing pstore is inadvertently causing a bunch of LLVM components to be installed even if they aren’t needed by the build (or perhaps simply haven’t been built yet). There were changes to the pstore cmake files process to make the standalone install work properly. Perhaps that broke something…

paulhuggett commented 3 years ago

Fixed by SNSystems/pstore@174d86ffa72f80618e02ea93699ffd2d6de8cda8.

paulhuggett commented 3 years ago

For future archaeologists, the above change probably needs some explanation.

After many attempts, I was unable to reproduce the original failure outside of the docker build. Inside, I was eventually able to reduce the collection of targets being installed to just pstore alone. This was enough to suggest that the llvm-dev message I mentioned above probably wasn’t (directly) related. It’s probably worth mentioning that, when built inside LLVM, pstore-dump will make use of the available disassembler. This creates a dependency between an install of pstore-dump and a number of LLVM components.

In the CMake scripts, we create a custom target named “install-pstore”. This is used by the LLVM build system to install pstore. This target then invokes the top-level install script to perform the installation. This is where the importance of tagging all of the installations with the pstore “component” becomes vital. Untagged installs are assigned to a default component.

Our install-pstore target then runs cmake with the -P (“Process script mode”) option and uses the -D options to set CMAKE_INSTALL_COMPONENT to pstore. Note that the order of these switches is significant.

By setting CMAKE_INSTALL_COMPONENT variable, we then filter all of the available targets so that only those tagged with the pstore COMPONENT. Previously (without the component tagging and the correct invocation of cmake) we would inadvertently install other parts of LLVM, including those that haven’t yet been built!