After #19685 started setting LDFLAGS, the INSTALL_RPATH_USE_LINK_PATH cmake option used in the libmultiprocess build no longer works, so it is neccessary to set CMAKE_INSTALL_RPATH as a fallback.
It’s unclear currently whether the bad interaction between INSTALL_RPATH_USE_LINK_PATH and LDFLAGS is a bug, but the issue is reported:
depends: Set CMAKE_INSTALL_RPATH for native packages
After #19685 started setting LDFLAGS, the INSTALL_RPATH_USE_LINK_PATH cmake
option used in the libmultiprocess build no longer works, so it is neccessary
to set CMAKE_INSTALL_RPATH as a fallback.
It's unclear currently whether the bad interaction between
INSTALL_RPATH_USE_LINK_PATH and LDFLAGS is a bug, but the issue is reported:
https://github.com/bitcoin/bitcoin/issues/19981#issuecomment-696680877
https://discourse.cmake.org/t/install-rpath-use-link-path-not-working-when-cmake-exe-linker-flags-ldflags-is-set/1892
Commands useful for building / testing this change
make -C depends MULTIPROCESS=1 print-libmultiprocess_cmake
make -C depends MULTIPROCESS=1 print-native_libmultiprocess_cmake
make -C depends MULTIPROCESS=1 HOST=x86_64-apple-darwin16 print-libmultiprocess_cmake
rm -rvf depends/x86_64-pc-linux-gnu/native depends/work/staging depends/work/build
make -C depends MULTIPROCESS=1 V=1 native_libmultiprocess_staged
for f in `find -name mpgen`; do echo == $f ==; readelf -d $f | grep -i path; done
make -C depends MULTIPROCESS=1 V=1 native_libmultiprocess_built
find -name CMakeCache.txt
Fixes #19981
7d0271b5c3
ryanofsky
commented at 2:29 pm on September 30, 2020:
member
This commit was originally part of #19160 but I’m making it a standalone PR because it seems to be causing travis timeouts on the macOS 10.12 build that I don’t know how to fix:
MarcoFalke added the label
Needs gitian build
on Sep 30, 2020
MarcoFalke added the label
Needs Guix build
on Sep 30, 2020
ryanofsky
commented at 3:41 pm on September 30, 2020:
member
Reproduced the travis macOS 10.12 timeout again:
https://travis-ci.org/github/bitcoin/bitcoin/jobs/731609242@MarcoFalke do you know any way to debug or fix this? I don’t think this PR is actually changing the build results. I think maybe all it is doing is invalidating the travis cache, and that macOS 10.12 travis build is too slow to update the cache. Does this sound right?
MarcoFalke
commented at 4:59 pm on September 30, 2020:
member
The build is probably failing altogether. For temporary debugging, you can remove the &> "/dev/null". Though, the &> "/dev/null" can’t be removed from master, because other builds would fail on travis due to too much output.
ryanofsky referenced this in commit
d9dc091b25
on Sep 30, 2020
ryanofsky
commented at 10:48 pm on September 30, 2020:
member
Thanks @MarcoFalke! It still looks to me that this PR might be uncovering a pre-existing problem with the macOS 10.12 build, and not actually causing the failure. Removing >/dev/null in d9dc091b257e9736d67ca8eeecbaf2da6682a3e5 shows the error “configure: error: Qt5Core >= 5.5.1 not found” (https://travis-ci.org/github/bitcoin/bitcoin/jobs/731743605#L2010) with debug output:
0configure:27263: checking for QT_CORE
1configure:27270: $PKG_CONFIG --exists --print-errors "${qt_lib_prefix}Core $qt_version" 2Package Qt5Core was not found in the pkg-config search path. 3Perhaps you should add the directory containing `Qt5Core.pc' 4to the PKG_CONFIG_PATH environment variable
5No package 'Qt5Core' found
6configure:27273: $?=1 7configure:27287: $PKG_CONFIG --exists --print-errors "${qt_lib_prefix}Core $qt_version" 8Package Qt5Core was not found in the pkg-config search path. 9Perhaps you should add the directory containing `Qt5Core.pc'10to the PKG_CONFIG_PATH environment variable
11No package 'Qt5Core' found
12configure:27290: $?=113configure:27304: result: no
14No package 'Qt5Core' found
15configure:27329: error: Qt5Core >=5.5.1not found
It’s good to have a starting point for debugging this, but am I wrong that this problem could be happening in master but masked by travis caching?
@dongcarl’s PR #19683 also has a failing macOS 10.12 build https://travis-ci.org/github/bitcoin/bitcoin/jobs/730372585, but it seems to be failing with a different problem a little earlier so it’s unclear if this Qt5Core error would happen there
dongcarl
commented at 10:59 pm on September 30, 2020:
member
FWIW I’m fairly certain the failure in #19683 is unrelated. As it’s due to over-specifying -fuse-ld= which clang treats as a -Wunused-command-line-argument warning, but because we also have -Werror on, it turns into an error.
ryanofsky
commented at 11:03 pm on September 30, 2020:
member
FWIW I’m fairly certain the failure in #19683 is unrelated. As it’s due to over-specifying -fuse-ld= which clang treats as a -Wunused-command-line-argument warning, but because we also have -Werror on, it turns into an error.
I’m also sure it’s unrelated. But since it happens before my error, if you fix it you might see the same problem there
ryanofsky
commented at 0:46 am on October 1, 2020:
member
It does appear the Qt5Core error is not related to the change in this PR. If I revert the original commit da6c9b7089d2cd0f5380d64882bd18f8794675f1, and just add a comment to funcs.mk 7472ee73d1541d822048c53157adc5030fbef5be, the error still happens: configure: error: Qt5Core >= 5.5.1 not found:
Which suggests the Qt5Core error is not related to the original macOS 10.12 timeouts #20046 (comment) and #20046 (comment), but maybe is caused by removing >/dev/null in d9dc091b257e9736d67ca8eeecbaf2da6682a3e5, or maybe is caused by more recent changes to master, or caused by other changes on travis. I guess I will try reverting the >/dev/null change d9dc091b257e9736d67ca8eeecbaf2da6682a3e5 to see if the timeout returns.
ryanofsky referenced this in commit
9aa445de3f
on Oct 1, 2020
ryanofsky
commented at 0:55 am on October 1, 2020:
member
I think I see why the Qt5Core error is happening. I was trying to debug in https://github.com/bitcoin/bitcoin/commit/d9dc091b257e9736d67ca8eeecbaf2da6682a3e5 by replacing source ./ci/test/05_before_script.sh &> "/dev/null" with source ./ci/test/05_before_script.sh &, but actually I need to drop the trailing & character, otherwise the before_script command doesn’t block at all.
ryanofsky referenced this in commit
e5d6dd0050
on Oct 1, 2020
ryanofsky force-pushed
on Oct 1, 2020
ryanofsky force-pushed
on Oct 1, 2020
ryanofsky
commented at 2:48 am on October 1, 2020:
member
After pushing e5d6dd00509d84de788d9f9f2d5511e2fe7c4c40, was able to reproduce the original macOS 10.12 error and get debug information: https://travis-ci.org/github/bitcoin/bitcoin/jobs/731786312#L4517. The error was CMake Error: TRY_RUN() invoked in cross-compiling mode building the native_cdrkit package
DrahtBot removed the label
Needs Guix build
on Oct 3, 2020
ryanofsky added this to the "In progress" column in a project
ryanofsky requested review from dongcarl
on Dec 8, 2020
ryanofsky requested review from fanquake
on Dec 8, 2020
fanquake
commented at 8:27 am on December 9, 2020:
member
ACK7d0271b5c30f86e4af175a5ab7df5e593cd85195 - I haven’t looked in depth, but I’ve re-read through #19981 and checked the failure by testing #19160 (with this reverted):
0 CXX bitcoin_node-bitcoind.o
1 CXX init/bitcoin_node-bitcoin-node.o
2 GEN ipc/capnp/echo.capnp.c++
3/home/ubuntu/bitcoin/depends/x86_64-pc-linux-gnu/native/bin/mpgen: error while loading shared libraries: libcapnpc-0.7.0.so: cannot open shared object file: No such file or directory
4make[2]: *** [/home/ubuntu/bitcoin/depends/x86_64-pc-linux-gnu/native/include/mpgen.mk:4: ipc/capnp/echo.capnp.c++] Error 127
Hopefully our upstream issue will get a reply at some point. Will wait for Carl to comment.
ryanofsky
commented at 5:45 pm on December 9, 2020:
member
Thanks for looking fanquake. Note original version of this PR was more complicated and ugly. Now that it’s is just setting CMAKE_INSTALL_RPATH for native packages, I think it’s pretty clean and straightforward. It may even a be good thing to set rpath explicitly and be clear the build looks for depends libraries ahead of system libraries
MarcoFalke added the label
Needs gitian build
on Dec 9, 2020
dongcarl
commented at 9:44 pm on December 9, 2020:
member
ACK7d0271b Looked into this a bit, it makes sense that for the things we build in depends, we want the library search to start in depends. It seems reasonable to expect this to happen automatically when CMAKE_INSTALL_PREFIX and INSTALL_RPATH_USE_LINK_PATH are set, but oh well…
I looked into the CMake codebase a bit, but couldn’t find a definite culprit for the weird CMAKE_INSTALL_RPATH_USE_LINK_PATH behaviour. It seems unintended, but we’ll see what the forums say I guess.
fanquake merged this
on Dec 10, 2020
fanquake closed this
on Dec 10, 2020
sidhujag referenced this in commit
7512d370e3
on Dec 10, 2020
MarcoFalke removed the label
Needs gitian build
on Dec 10, 2020
ryanofsky moved this from the "In progress" to the "Done" column in a project
This is a metadata mirror of the GitHub repository
bitcoin/bitcoin.
This site is not affiliated with GitHub.
Content is generated from a GitHub metadata backup.
generated: 2024-11-17 12:12 UTC
This site is hosted by @0xB10C More mirrored repositories can be found on mirror.b10c.me
