2) The other problem is that the paths specified have to be relative to the application. (Of the top of my head) It doesn't support absolute paths. Which means I can't have GHC generate the entry because I have no idea where the testsuite intends to run the binary. One way around this is to have the testsuite generate the needed config file. That should be do-able.
I'll investigate this method first. I had discarded it for some reason before but now can't remember...
Right, it sounds like this is a workable option and the fact that it requires adding no further complexity to the compiler is quite a merit. The only question is what other use-cases might run into this same issue. For instance, what happens when I run `cabal build` and try to run an executable from `dist/build`. Then I run `cabal install` and run it from `.cabal/bin`. Surely Cabal will need to take some sort of action in this case. I suppose this means that using plain `ghc -dynamic` alone is probably out of the question.
No, this would only be the case for development versions of GHC. For the end user, the GHC core libraries *should* be registered in the SxS cache (much like the Microsoft, Intel, etc compilers do). This is part of the distribution story we still have to have a chat about. For user libraries, it wouldn't matter since the application would check the SxS Cache and it would always work. Also the SxS assembly creation is opt-in. So if you rely on a dll, even one created by GHC (and not a core library) then by default it won't be an SxS assembly (as is currently the case.). This does however mean, that if you just use the tarball, you can't run programs created with -dynamic. In the implementation I also have an override `-fno-gen-sxs-assembly` which will create a binary which will not try to use SxS at all to find it's depencencies. In this case you'd have to have the proper PATH entries. So by adjusting your PATH you can still get the development/in-place ghc to run from abritrary locations. Since this method can't be used to satisfy the loader than that the right runtime was already loaded it does mean that Stack won't be able to support -dynamic out of the box. However they can probably get it to work using the same methods the testsuite uses. The testsuite always compiles applications using this override, and then corrects the PATH entries before running. This is why a large part of the tests still run fine.