prevent configure script of recent BLAST+ versions from prepending system paths to $PATH#20751
Conversation
|
@boegelbot please test @ generoso |
|
@bedroge: Request for testing this PR well received on login1 PR test command '
Test results coming soon (I hope)... Details- notification for comment with ID 2152667233 processed Message to humans: this is just bookkeeping information for me, |
|
Test report by @bedroge |
|
Test report by @bedroge |
|
@boegelbot please test @ jsc-zen3 |
|
@bedroge: Request for testing this PR well received on jsczen3l1.int.jsc-zen3.fz-juelich.de PR test command '
Test results coming soon (I hope)... Details- notification for comment with ID 2153015137 processed Message to humans: this is just bookkeeping information for me, |
|
Test report by @boegelbot |
|
Test report by @boegelbot |
|
Test report by @boegel |
|
Going in, thanks @bedroge! |
@TopRichard found that when RPATH support is enabled BLAST+ fails on some systems (mostly on distros with more recent GCC versions, it seems) due to:
Only this executable was using RUNPATH instead of RPATH, all the other ones in the installation did have RPATH. This executable actually gets compiled at the end of the
configurescript, and it turned out that it's using the system GCC compiler (and using--enable-new-dtags). By debugging it a bit more and replacing my system compiler by a bash script that spits out some more information, I found that$PATHwas actually changed, and this lead me to the following linesrc/build-system/configure:By commenting that line, it now picks up the right compiler (or actually the RPATH wrappers, assuming RPATH support enabled), and it gets compiled with the proper flags. The RPATH wrappers make sure that
--enable-new-dtagsis changed into--disable-new-dtags, which ensures that RPATH instead of RUNPATH is used.