Wrong rpath for dynamically linked tests

[bennofs]

Problem description

When using using --enable-executable-dynamic for a package where the tests depend on a library defined in the same file, the rpath for tests is set to the installation directory of the library, not to the dist/build directory. This means that the tests cannot be run before the library is installed.

An example project is here: https://github.com/bennofs/cabal-tests-rpath

That project defines a library foo and a test-suite dependent on that library. Running the tests with --enable-executable-dynamic gives:

dist/build/tests/tests: error while loading shared libraries: 
  libHSfoo_67YeKrejATQ1VvsAysOhCH-ghc7.10.0.20150123.so: 
    cannot open shared object file: No such file or directory

(It also happens with ghc 7.8, it's not related to 7.10, except that 7.10 ships 1.22 by default while 7.8 ships the working 1.18 version)

Cause

Inspecting the rpath shows:

$ patchelf --print-rpath dist/build/tests/tests
/usr/local/lib/x86_64-linux-ghc-7.10.0.20150123/foo_67YeKrejATQ1VvsAysOhCH:...

Note that only the path of the library if it would be installed is placed in the rpath, not the build directory.

This happens with Cabal 1.22. At least with Cabal 1.18, this was not the case, the rpath was instead correctly set to dist/build. I have not tested Cabal 1.20.

[bennofs]

Looking at the code, I noticed that running the tests via cabal should set (DY)LD_LIBRARY_PATH accordingly. So the question is now, should tests (and I assume the same applies for executables) be directly runnable without installation, without using cabal run or cabal test? That would mean hardcoding the build directory in the RPATH, which might not be desirable.

[bennofs]

Confirmed, runhaskell ./Setup.hs test works as expected.

[ttuegel]

I'm confused about what the issue is here. Is the problem that cabal test works, but running the test executable directly does not?

[bennofs]

@ttuegel yes, because cabal test sets LD_LIBRARY_PATH, which of course is not set when you run the executable directly.

[ttuegel]

@bennofs Got it. It was not clear to me if the problem was ./setup test worked, but not cabal test.

@christiaanb Is it possible to actually set the RPATH of tests to the in-place-installed library?

[christiaanb]

I think adding an rpath to the inplace library directory is unwanted and ugly, see also: #2330 (comment)

Also, this is exactly what cabal run is for:

cabal run - New command that compiles and runs the given executable. Instead of cabal build && ./dist/build/prog/prog --args, you can now use cabal run prog -- --args.

edit: ah, I see this is with regards to the testing executable. Indeed, then cabal test works just fine. What is the particular reason not to use cabal test?

[bennofs]

@christiaanb For tasty, the output is nicer if I don't use cabal test (even with streaming, cabal test will not show the progress of a single test case I believe and also doesn't show colors :)

Also, I sometimes want to pass additional commands to a particular test-suite (for example, to reproduce a problem by specifying the QuickCheck initial seed). Is this possible with cabal test?

[ttuegel]

@bennofs The lack of colors/progress indicators is due to your test framework; cabal cannot display those things if they are stripped from the output (which is what every framework seems to do to us). The detailed-1.0 test interface will eliminate that problem. There is no way to specify per-test options at this time, but there is a ticket for that.