On Thu, May 20, 2010 at 1:42 PM, Brandon S. Allbery KF8NH <allb...@ece.cmu.edu> wrote: > On May 20, 2010, at 08:29 , John Lato wrote: >> >> On Thu, May 20, 2010 at 1:07 PM, Brandon S. Allbery KF8NH >> <allb...@ece.cmu.edu> wrote: >>> >>> On May 20, 2010, at 06:23 , Simon Marlow wrote: >>>> >>>> On 18/05/2010 17:48, John Lato wrote: >>>>>> >>>>>> From: Simon Marlow<marlo...@gmail.com> >>>>>>> >>>>>>> But currently there is one problem with "GhcShared=YES": with this >>>>>>> option, the stage-2 compiler gets linked dynamically but the >>>>>>> corresponding inplace shell wrapper does not set (DY)LD_LIBRARY_PATH, >>>>>>> thus ./inplace/bin/ghc-stage2 doesn't run at all. I could work around >>>>>>> this by manually symlinking all the dynamic libraries to >>>>>>> ./inplace/lib >>>>>>> and setting (DY)LD_LIBRARY_PATH to there, but obvisouly there should >>>>>>> be a solution better than this. >>>>>> >>>>>> On Linux we link the binary using -rpath (I know OS X doesn't have >>>>>> -rpath). This is another issue we need to resolve before we can >>>>>> switch >>>>>> to a dynamically-linked GHCi. >>>>> >>>>> When you say OSX doesn't have -rpath, do you mean there's some problem >>>>> with using -rpath on OSX? I have code that links to a 3rd-party >>>>> library (libcudart.dylib) at runtime and it seems to use -rpath fine. >>>>> This is with ghc-6.12.1. >>>> >>>> It was my understanding that OS X doesn't have -rpath from reading >>>> >>>> http://hackage.haskell.org/trac/ghc/wiki/SharedLibraries/Management >>>> >>>> and from what I remember Mac people saying in the past. Or maybe they >>>> were just saying that -rpath is not the right thing on OS X because >>>> libraries themselves have paths baked in. >>> >>> The latter. Also, I'd recommend DYLD_FALLBACK_LIBRARY_PATH per Apple >>> recommendations, as you can otherwise get weird results. >> >> According to the dyld docs, it looks like -rpath is meant to be used >> as a last resort when other mechanisms aren't feasible. In >> particular, "The use of @rpath is most useful when you have a >> complex directory structure of programs and dylibs which can be >> installed anywhere, but keep their relative positions." [1] >> >> I suppose I'd agree that it's best avoided on OSX if it can be helped. > > Interesting, considering that Apple's recommended use case appears to be > exactly what we're looking for.
In that case, maybe -rpath is the right thing to do? I don't know much about Apple's dev. guidelines, so I won't make any recommendations. > > Oh, also? �...@rpath isn't mentioned in dyld(1) on Leopard and is barely > referenced in ld(1), which is why I missed it (and probably part of why > -rpath was ignored). > At my most charitable, I'd describe Apple's docs for command-line tools incomplete at best. John _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users