Am 24.10.2017 um 20:02 schrieb Moritz Angermann <moritz.angermann@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.)
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/D4121On Oct 24, 2017, at 9:54 AM, Moritz Angermann <moritz.angermann@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,
MoritzOn Oct 24, 2017, at 9:45 AM, Manuel M T Chakravarty <chak@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,
ManuelAm 23.10.2017 um 17:04 schrieb Moritz Angermann <moritz.angermann@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