Revert "tests: use RUNPATH instead of RPATH consistently (#309)"

[jnpkrn]

This reverts commit eeb5e45.

Said change did not undergo standard review and seems superfluous,
since we inject neither RPATH nor RUNPATH into the resulting shared
library, therefore it's questionable why we should be carrying this
burden and influence anything by force. Redistributors are free to
make their own choices. If that requires assistance on libqb's side,
their conditional patches are welcome.

Signed-off-by: Jan Pokorný [email protected]

[fabbione]

nack.
RUNPATH is required for the test suite to work properly on some combinations of OS/toolchain, otherwise the test suite can fail or use the OS installed libqb.

[fabbione]

Also:

1. read the comment in the original commit properly, it explains why this is necessary to run properly the test suite. How can you define it superfluous if it fixes the test suite?
2. as mentioned in the original comment, libqb it self was not affected and it is not affected. It is merely to execute the test suite properly
3. what is the gain of reverting the patch and introduce a regression in the test suite?
4. the primary re-distributor that has this issue is RHEL and Fedora btw that still defaults to the old linker behavior.
5. the patch was acked by Chrissie on IRC, given that the code didn't influence any function in the main library we just did a quick turnaround.

[chrissie-c]

NACK. I'm not reverting a change just because you didn't get to review it.

[jnpkrn]

Misunderstanding emerges.

I am all for retaining that provided that the reason is properly justified.
So far, it appears just as an additional complexity not paralleled elsewhere.
The main purpose of this dispute is to remove the entangled obscurity with
said commit, something not very helpful for an open source project.

Can you answer these simple questions, please, so we may go forward?

1. Does kronosnet test suite use system-wide libqb or does it consume it
   internally as an subproject, via libtool depending on its *.la files etc.?

2. Does kronosnet test suite require libqb compiled with any sort of
   dynamic linker search path overrides (*RPATH, *RUNPATH)?

3. Is there any actual risk libqb would taint intended separation by
   being used to load any libraries transitively? -- this is the only case I can
   imagine would need this rectification.

Please, enlighten me, which configuration in particular is troubling to
the extent said commit is necessary. Thank you.

[fabbione]

On 9/17/18 2:39 PM, Jan Pokorný wrote: Misunderstanding emerges. I am all for retaining that provided that the reason is properly justified.

It is written in the original commit. assume you have libqb installed on the system (via whatever package manager) and you run the test suite: 1) WITHOUT this commit, the test binaries will use the installed libqb and not the currently built one 2) WITH this commit, the test binaries will use the newly built libqb in the source tree as expected.

So far, it appears just as an additional complexity not paralleled elsewhere. The main purpose is to remove the entangled obscurity with said commit, something not very helpful for an open source project. Can you answer these simple questions, please, so we may go forward? 1. Does kronosnet test suite use system-wide |libqb| or does it consume it internally as an subproject, via |libtool| depending on its |*.la| files etc.?

Completely irrelevant. This commit to libqb is a port of a similar fix for knet.

2. Does kronosnet test suite require |libqb| compiled with any sort of dynamic linker search path overrides (|*RPATH|, |*RUNPATH|)?

knet doesn't require libqb for anything but generating documentation.

3. Is there are any actual risk |libqb| would taint intended separation by being used to load any libraries transitively -- this is the only case I can imagine would need this rectification.

Nope, because knet does not use and will not use libqb.

Please, enlighten me, which configuration in particular is troubling to the extent said commit is necessary. Thank you.

Your *own* test suite. Fabio

…

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <#323 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAW6rdP-CMGAww1fYq4c96U3e_yXyOErks5ub5frgaJpZM4WplOH>.

[jnpkrn]

Please, enlighten me, which configuration in particular is troubling to
the extent said commit is necessary. Thank you.

Your own test suite.

Ah, I start to see, I really wish the initial problem statement was
less obfuscated (which is one of the purposes for patch review).

So does it mean that:

a. libtool on some systems (Debian?) will compile test suite binaries
with RPATH unconditionally and automatically...

b. ...which libtool's wrapper scripts for these binaries will try to
override then with LD_LIBRARY_PATH=... definition, which will fall
short to achieve the override (as only RUNPATH can be overridden?)

Or is the reproducing scenario different?

[fabbione]

On 9/17/18 3:25 PM, Jan Pokorný wrote: Please, enlighten me, which configuration in particular is troubling to the extent said commit is necessary. Thank you. Your /own/ test suite. Ah, I start to see, I really wish the initial problem statement was less obfuscated (which is one of the purposes for patch review). So does it mean that: a. |libtool| on some systems (Debian?) will compile test suite binaries with |RPATH| unconditionally and automatically...

All systems but Fedora and RHEL use RUNPATH by default (maybe FreeBSD).

b. ...which |libtool|'s wrapper scripts for these binaries will try to override then with |LD_LIBRARY_PATH=...| definition, which will fall short to achieve the override (as only |RUNPATH| can be overridden?)

Correct.

Or is the reproducing scenario different?

That's correct.

…

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#323 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAW6rcIOzbldW4LrhM0ORXo2SLhV6ognks5ub6LJgaJpZM4WplOH>.