> Am 24.10.2017 um 20:02 schrieb Moritz Angermann <moritz.angerm...@gmail.com>:
>
> 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.)
Awesome!
> 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.
Yes, that’s why I took the hacky short-cut of running the normal install
procedure and then patching the libs up in place with ’install_name_tool’.
(BTW, a not too widely known tool that makes messing with dylibs, RPATHs, and
signatures way nicer than otool is <http://newosxbook.com/tools/jtool.html
<http://newosxbook.com/tools/jtool.html>> — the output is so much more
readable.)
> 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.
I hear you.
Cheers,
Manuel
> 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
