cmake: Keep RPATH for the bitcoin-chainstate target in the build tree

[hebasto]

This is a follow-up of bitcoin#30312 and #236.

On staging branch @ 8b80c1a:

$ cmake -B build -DBUILD_UTIL_CHAINSTATE=ON -DBUILD_SHARED_LIBS=ON
$ cmake --build build -t bitcoin-chainstate
$ ./build/src/bitcoin-chainstate
./build/src/bitcoin-chainstate: error while loading shared libraries: libbitcoinkernel.so: cannot open shared object file: No such file or directory

This PR fixes this issue and adds a new CI job to check it.

[hebasto]

cc:

• @fanquake, as an author of contrib: add R(UN)PATH check to ELF symbol-check bitcoin/bitcoin#30312
• @m3dwards and @theuni, as reviewers of cmake: Do not add rpath information to compiled executables #236

[theuni]

I don't understand this. Don't we always want the BUILD_RPATH for bitcoin-chainstate so that it works with a shared kernel in the build tree? Then it's stripped for the INSTALL_RPATH binary and everyone's happy?

[hebasto]

Don't we always want the BUILD_RPATH for bitcoin-chainstate so that it works with a shared kernel in the build tree?

We do, of course.

I mean, in the future, this code:

bitcoin/CMakeLists.txt

Lines 606 to 607 in 02d9f7f

	set(CMAKE_SKIP_BUILD_RPATH TRUE)
	set(CMAKE_SKIP_INSTALL_RPATH TRUE)

can be just:

set(CMAKE_SKIP_INSTALL_RPATH TRUE) 

which effectively makes set_target_properties(bitcoin-chainstate PROPERTIES SKIP_BUILD_RPATH OFF) redundant.

Or do you mean always keep it for the purpose of explicitness?

[m3dwards]

ACK f39a181

[theuni]

I guess I'm just having trouble understanding the goal here at a high-level.

I've verified (locally) that the runpath now exists in the build-tree, and thus bitcon-chainstate works. But doesn't that mean that the runpath check (in master) will now fail? Don't we need to fix that upstream first?

[hebasto]

@theuni

I guess I'm just having trouble understanding the goal here at a high-level.

I've verified (locally) that the runpath now exists in the build-tree, and thus bitcon-chainstate works. But doesn't that mean that the runpath check (in master) will now fail? Don't we need to fix that upstream first?

But the bitcon-chainstate binary is not a subject of the runpath check at this moment, right?

[theuni]

@theuni

I guess I'm just having trouble understanding the goal here at a high-level.
I've verified (locally) that the runpath now exists in the build-tree, and thus bitcon-chainstate works. But doesn't that mean that the runpath check (in master) will now fail? Don't we need to fix that upstream first?

But the bitcon-chainstate binary is not a subject of the runpath check at this moment, right?

Ah, ok, that's the part I was missing. Thanks. Seems it should be added, as part of the upstream guix changes to check the install tree.

[theuni]

ACK f39a181

[hebasto]

@theuni

I guess I'm just having trouble understanding the goal here at a high-level.
I've verified (locally) that the runpath now exists in the build-tree, and thus bitcon-chainstate works. But doesn't that mean that the runpath check (in master) will now fail? Don't we need to fix that upstream first?

But the bitcon-chainstate binary is not a subject of the runpath check at this moment, right?

Ah, ok, that's the part I was missing. Thanks. Seems it should be added, as part of the upstream guix changes to check the install tree.

Sorry, but I have to clarify. The bitcon-chainstate binary is not configured for build in the Guix script.