Hi *,
so I've given this a stab[1]. While getting the wrapper requirement,
and the .conf files sorted was rather easy. (We already have getExecutablePath,
and the relocatable logic for windows. As well as $topdir and ${pkgroot}
support for paths in .conf files.)
Now as Manuel laid out the dynamic libraries situation is a bit annoying.
Specifically as the ghc-stage2 we build *in-tree*, and the libraries have
a completely different layout from the final install location. And as such
setting @rpath, and @loader_path, is quite tricky, as essentially the
installation is not a relocation of the stage1 or stage2 compiler.
However, I am now again at the point where I start hacking on the build
system, while Hadrian is imminent. And this is quite depressing.
Cheers,
Moritz
--
[1]: https://phabricator.haskell.org/D4121
> On Oct 24, 2017, at 9:54 AM, Moritz Angermann <moritz.angerm...@gmail.com>
> wrote:
>
> 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
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
