I have resolved this issue by adding the rpath to the dependent package's ldOptions [1], but I'm not particularly happy with it.

My solution was inspired by an old post describing a similar problem with rpath [2], was this ever looked at?

[1] http://darcsden.com/DukeDave/wxhaskell-dev/patch/20120103181105-a1f0b
[2] http://www.haskell.org/pipermail/cabal-devel/2007-June/000588.html


On 24 December 2011 01:32, Dave Tapley <dukedave@gmail.com> wrote:
Hi all,

I've been working on a new development version of wxhaskell[1] and one of my goals was to integrate previous work on using a shared library[2].
I'm please to report that I have more-or-less achieved this goal at least under Linux, but there is still some cleaning up to do.

After performing a cabal I end up with a .so file as expected, the only problem currently is that now whenever you compile something which uses wxhaskell you have to pass in an rpath to the .so in the cabal-dev / local / system packages location.

Obviously this .so somehow needs to end up where the system can find it, and I wondered if someone has already (or has ideas about how to) make this happen in cabal?

You can see where I believe it should fit in in the ldconfig function in Setup.hs[3].

Thanks,
Dave


[1] http://darcsden.com/DukeDave/wxhaskell-dev
[2] http://wewantarock.wordpress.com/2010/11/03/building-a-shared-library-in-cabal/
[3] http://darcsden.com/DukeDave/wxhaskell-dev/browse/wxc/Setup.hs