Hi Manuel, thanks for the link! Ahh yes lovely RPATH (this reminds me, I should look to verify if I can make GHC link recursively.) The conf files came up on #ghc yesterday as well. Maybe we need some $home, $sysroot or similar marker to make them relocatable.
I'll probably take a crack at this today. Not sure how far I get though. The primary motivation is that packaging the cross compilers in a neat way looks like layering patched upon patches onto the configure script. And in light of Hadrian, we might just want to package up a directory and not deal with the binary-dist logic where we can? Cheers, Moritz > On Oct 24, 2017, at 9:45 AM, Manuel M T Chakravarty <c...@justtesting.org> > wrote: > > Hi Moritz, > > Haskell for Mac is fully relocatable (as every Mac users expects this of a > Mac app). > > Unfortunately, it is not just the libdir in the wrapper scripts that’s in the > way of a relocatable GHC. Additional problems are (1) the (at least, as of > 8.0) still not macOS-friendly RPATHs in dynamic libraries and (2) the > absolute paths in package .conf files. > > In Haskell for Mac, I use two arguably hacky solutions to those two issues. I > rewrite all RPATHs in .dylibs to be relative and I have got a little tool > that relocates .conf files. I’d certainly prefer a cleaner solution! > > Those aspects of Haskell for Mac are actually in a separate framework > (GHC.framework) that wraps GHC and some other tools. This is all in a public > repo if you like to have a look > > https://github.com/haskellformac/GHCframework > > I haven’t put a license on it, but I’d be happy to make it all BSD3. It is of > course all highly Mac specific and requires Xcode to build for all the code > signing, sandboxing, etc. > > Cheers, > Manuel > >> Am 23.10.2017 um 17:04 schrieb Moritz Angermann <moritz.angerm...@gmail.com>: >> >> Hi, >> >> while trying to make the binary-distribution logic work for >> cross compilers. I've come wonder, how hard it could be to >> make GHC relocatable. (e.g. just unpack the distribution, >> and use the compiler from the `bin` folder within). >> >> Right now this does not work due to the need for the path to >> package.conf, and this is hardcoded in the wrapper script to >> provide the proper libdir to ghc via -B[1]. Supposedly this >> is not an issue on Windows, as a relative path is common on >> windows and finding the location of the executable can be done >> safely. Or that's at least how I understand[1]. >> >> For macOS there is the haskell-platform, and ghc-dot-app[2] >> >> From [3], it sounds like automake is a build, and not a packaging >> system, and the binary dist usecase with configure is not >> really a standard use case. >> >> So why do I bring this up NOW? Apart from me trying to make >> cross compiler binary distributions working? The reason is >> that we are also trying to move towards hadrian, and by "starting >> from scratch", maybe we have a chance to reconsider how we >> do things? >> >> I must admit, I'm quite happy to use packages like llvm, by >> just downloading a package and adding the `bin` path to my >> $PATH. >> >> There is however one thing that the current configure appraoch >> does, which I think is quite noteworthy (apart from setting >> $prefix). That is, it does check for compilers and sets them >> accordingly, which might be desirable. >> >> Cheers, >> Moritz >> >> -- >> [1]: https://ghc.haskell.org/trac/ghc/wiki/Building/Installing >> [2]: https://ghc.haskell.org/trac/ghc/wiki/Building/MacOSX/Installer >> [3]: https://lists.gnu.org/archive/html/automake/2006-10/msg00005.html >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
