Installing in ${HOME}/.local causes build error #134

1. 
   hebasto commented at 8:35 am on January 24, 2025: member

   On Ubuntu 24.04, with a patch from https://github.com/chaincodelabs/libmultiprocess/pull/133 applied:

   0# In Libmultiprocess repo
   1$ cmake -B build
   2$ cmake --build build
   3$ cmake --install build --prefix "${HOME}/.local"
   

    0# In Bitcoin Core repo
    1$ cmake -B build -DWITH_MULTIPROCESS=ON
    2$ cmake --build build -t bitcoin-node
    3[280/344] Generating capnp/common.capnp.c++, capnp/common.capnp.h, capnp/common....proxy-server.c++, capnp/common.capnp.proxy-types.c++, capnp/common.capnp.proxy.h
    4FAILED: src/ipc/capnp/common.capnp.c++ src/ipc/capnp/common.capnp.h src/ipc/capnp/common.capnp.proxy-client.c++ src/ipc/capnp/common.capnp.proxy-types.h src/ipc/capnp/common.capnp.proxy-server.c++ src/ipc/capnp/common.capnp.proxy-types.c++ src/ipc/capnp/common.capnp.proxy.h /home/hebasto/git/bitcoin/build/src/ipc/capnp/common.capnp.c++ /home/hebasto/git/bitcoin/build/src/ipc/capnp/common.capnp.h /home/hebasto/git/bitcoin/build/src/ipc/capnp/common.capnp.proxy-client.c++ /home/hebasto/git/bitcoin/build/src/ipc/capnp/common.capnp.proxy-types.h /home/hebasto/git/bitcoin/build/src/ipc/capnp/common.capnp.proxy-server.c++ /home/hebasto/git/bitcoin/build/src/ipc/capnp/common.capnp.proxy-types.c++ /home/hebasto/git/bitcoin/build/src/ipc/capnp/common.capnp.proxy.h 
    5cd /home/hebasto/git/bitcoin/build/src/ipc && /home/hebasto/.local/bin/mpgen /home/hebasto/git/bitcoin/src/ipc /home/hebasto/git/bitcoin /home/hebasto/git/bitcoin/src/ipc/capnp/common.capnp
    6/home/hebasto/git/bitcoin/src/ipc/capnp/common.capnp:10:22-39: error: Import failed: /mp/proxy.capnp
    7/home/hebasto/git/bitcoin/src/ipc/capnp/common.capnp:11:2-7: error: Not defined: Proxy
    8/home/hebasto/git/bitcoin/src/ipc/capnp/common.capnp:13:18-23: error: Not defined: Proxy
    9terminate called after throwing an instance of 'std::runtime_error'
   10  what():  Invoking /usr/bin/capnp failed
   11Aborted (core dumped)
   12ninja: build stopped: subcommand failed.
   

   0$ printenv PATH
   1/home/hebasto/.cargo/bin:/home/hebasto/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/snap/bin
   

2. 
   ryanofsky commented at 8:10 pm on January 24, 2025: collaborator

   Thanks for the bug report! This is interesting and I learned some things.

   tl;dr: recommended fix is to use -DCMAKE_INSTALL_PREFIX=$HOME/.local earlier at configure time instead of using --prefix $HOME/.local install option later.

   Few observations:

   • On my system in order to reproduce this I had to set CMAKE_PREFIX_PATH=$HOME/.local in the environment during the cmake -B build -DWITH_MULTIPROCESS=ON step, otherwise it would not find the package. I’m not sure if cmake uses $HOME/.local by default on other systems.

   • A slightly faster way for me to make the problem happen instead of running cmake --build build -t bitcoin-node was to run make -C build bitcoin_ipc

   • Cause of the problem is that paths to capnproto include directories currently get compiled into the mpgen executable. You can verify this by running strings ~/.local/bin/mpgen | grep /include. So if cmake does not know the install prefix at configure time it will not build the executable correctly.

   • Recommended fix would be run cmake -B build -DCMAKE_INSTALL_PREFIX=$HOME/.local

     • This will build mpgen executable correctly, and lets you more conveniently run cmake --install build or make -C build install without needing to repeat the install prefix, because it is saved in the configuration.

   • Possible follow-ups to address this issue might be:

     • Improving documentation to recommend using -DCMAKE_INSTALL_PREFIX, or configuring cmake graphically, instead of passing --prefix to the install command.

     • Maybe making it an error in the install script to specify a different –prefix value that does not match CMAKE_INSTALL_PREFIX. Not sure if this is possible with cmake scripting.

     • Changing mpgen executable to try to detect include paths at runtime instead of compile time. This might be challenging though. It should not be too difficult for it to find the libmultiprocess include directory (needed to import “/mp/proxy.capnp”). But I’m not sure how it could determine the capnproto include path at runtime (needed to import “/capnp/c++.capnp”)

     • Maybe the target_capnp_sources function could automatically work around this issue, if it can determine the Libmultiprocess install path from cmake variables and add pass the include path as an extra argument to the mpgen command line.

   • For purposes of Bitcoin project, this problem might become mooted if Libmultiprocess can be a git subtree configured with add_subdirectory, since in that case there shouldn’t be any installation step needed.

3. 
   ryanofsky commented at 7:18 pm on January 27, 2025: collaborator

   Some of the followups listed in previous comment are probably still a good idea, but note that with the https://github.com/bitcoin/bitcoin/pull/31741 there is probably less of a reason to want to install libmultiprocess as a separate package, so that makes it less likely someone would encounter problems using cmake –install –prefix. It is still pretty useful to install it as a separate package in order to be able to work with this git repository though, so I should at least document fact that that –prefix option can lead to problems and CMAKE_INSTALL_PREFIX should be preferred instead.
4. 
   purpleKarrot commented at 3:37 pm on May 16, 2025: contributor

   Making sure that the installation path is known at configure time is a workaround. The underlying problem is that the installation is not relocatable.

Contributors
hebasto ryanofsky purpleKarrot