
Randy Polen, undertook porting the new build of Haskell Platform to Windows. He did a great job... but as this is first time stepping up to such a big release, he has some questions about GHC and Windows, and the choices he had to make. He asked me to forward these to this list, as he's not a member. He's cc'd so you can reply to all and include him... or I can forward as needed.
From Randy:
I am building the Haskell Platform 2014.2.0.0 on the Windows side. Your advice would be very helpful to make sure the HP 2014 for Windows is as good as possible. There were some issues I worked-around, plus some features that seem to not be available in this particular GHC (7.8.3) on the 32-bit and 64-bit Windows platforms, and I would like to confirm that HP 2014.2.0.0 will be shipping something sensible and as expected for the Windows environment, noting things which are supported on other environments but not on Windows. * GHC 7.8.3 on Windows does not support building Haskell into shared libraries, (GHC ticket #8228) so all packages in HP 2014.2.0.0 for Windows have been built without --enable-shared * GHC 7.8.3 on Windows does not currently support LLVM (GHC ticket #7143) * All Windows HP 2014.2.0.0 packages have been built without --enabled-split-objs, in deference to the GHC 7.8 FAQ * Extra python, etc. bits included in the GHC 7.8.3 bindist for 64-bit Windows (GHC issue #9014) are not installed with Windows HP 2014.2.0.0. Is eliding them from the HP 2014.2.0.0 64-bit Windows installation safe and correct (i.e., are they truely not required)? * Missing src/html in GHC packages were worked around by replacing the entire GHC package doc tree of html files with the contents of the "Standard Libraries" tarball (but not for the two packages which are not built for Windows, terminfo and unix). Is this valid to do? Any issues might arise? * ref: http://www.haskell.org/ghc/docs/latest/libraries.html.tar.bz2 Thanks for any advice on these. I do want to make the Windows HP 2014.2.0.0 be as good as it can be. Randy

2014-08-02 4:49 GMT+02:00 Mark Lentczner
[...] * All Windows HP 2014.2.0.0 packages have been built without --enabled-split-objs, in deference to the GHC 7.8 FAQ [...]
Do you have an URL for this FAQ? I can't find it, and I can't remember what's wrong with --enable-split-objs. :-( What is the impact for people using large libraries (like OpenGL/OpenGLRaw/...) where you often use only a small part? Will you get a huge executable then? IIRC that's at least the case for Linux. Cheers, S.

Hi,
On 4 August 2014 14:52, Sven Panne
Do you have an URL for this FAQ? I can't find it, and I can't remember what's wrong with --enable-split-objs. :-( What is the impact for people using large libraries (like OpenGL/OpenGLRaw/...) where you often use only a small part? Will you get a huge executable then? IIRC that's at least the case for Linux.
https://ghc.haskell.org/trac/ghc/wiki/GHC-7.8-FAQ One of the problems is that split-objs is extremely slow, especially on Windows. I had to disable split-objs for OpenGL-related libraries when building the HP installer in the past because of this. Randy also said that libraries built with split-objs don't work well in ghci on Windows x64.

2014-08-04 14:59 GMT+02:00 Mikhail Glushenkov
Hmmm, this isn't very specific, it just says that there are probably bugs, but that's true for almost all code. :-) Are there any concrete issues with --enable-split-objs?
One of the problems is that split-objs is extremely slow, especially on Windows. I had to disable split-objs for OpenGL-related libraries when building the HP installer in the past because of this.
I think it's perfectly fine if the the compilation of the library itself takes ages if it pays off later: You compile the library once, but link against it multiple times. Or do the link times against e.g. OpenGL stuff suffer? My point is: Do we make the right trade-off here? A quick search brought up e.g. https://github.com/gentoo-haskell/gentoo-haskell/issues/169 which seems to be a request to split everything.
Randy also said that libraries built with split-objs don't work well in ghci on Windows x64.
Is there an issue for this?

On Mon, Aug 4, 2014 at 8:50 AM, Sven Panne
2014-08-04 14:59 GMT+02:00 Mikhail Glushenkov
: Hmmm, this isn't very specific, it just says that there are probably bugs, but that's true for almost all code. :-) Are there any concrete issues with --enable-split-objs?
Sorry for the confusion; I just meant you *should not* enable split-objs in your cabal configuration - GHC uses it for its libraries, but in general users don't want it for arbitrary code (bugs, huge linking time and memory usage, etc).
One of the problems is that split-objs is extremely slow, especially on Windows. I had to disable split-objs for OpenGL-related libraries when building the HP installer in the past because of this.
I think it's perfectly fine if the the compilation of the library itself takes ages if it pays off later: You compile the library once, but link against it multiple times. Or do the link times against e.g. OpenGL stuff suffer? My point is: Do we make the right trade-off here? A quick search brought up e.g. https://github.com/gentoo-haskell/gentoo-haskell/issues/169 which seems to be a request to split everything.
Randy also said that libraries built with split-objs don't work well in ghci on Windows x64.
Is there an issue for this?
Yes, there should be a bug filed for this if there isn't one already. But problems with the GHC build itself are really more of the priority than arbitrary user facing code. Still, a ticket would be good.
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

Hi,
On 4 August 2014 15:50, Sven Panne
I think it's perfectly fine if the the compilation of the library itself takes ages if it pays off later: You compile the library once, but link against it multiple times.
Building GL* with -split-objs on Windows is like watching paint dry (and it has to be done multiple times for shared and profiling variants). But I agree in general. Current HP installer uses -split-objs for all libraries except GL*.

Mark, Randy,
Sorry for the delayed reply!
On Fri, Aug 1, 2014 at 9:49 PM, Mark Lentczner
Randy Polen, undertook porting the new build of Haskell Platform to Windows. He did a great job... but as this is first time stepping up to such a big release, he has some questions about GHC and Windows, and the choices he had to make. He asked me to forward these to this list, as he's not a member. He's cc'd so you can reply to all and include him... or I can forward as needed.
From Randy: ------------------ I am building the Haskell Platform 2014.2.0.0 on the Windows side. Your advice would be very helpful to make sure the HP 2014 for Windows is as good as possible.
There were some issues I worked-around, plus some features that seem to not be available in this particular GHC (7.8.3) on the 32-bit and 64-bit Windows platforms, and I would like to confirm that HP 2014.2.0.0 will be shipping something sensible and as expected for the Windows environment, noting things which are supported on other environments but not on Windows.
* GHC 7.8.3 on Windows does not support building Haskell into shared libraries, (GHC ticket #8228) so all packages in HP 2014.2.0.0 for Windows have been built without --enable-shared
That's correct.
* GHC 7.8.3 on Windows does not currently support LLVM (GHC ticket #7143)
Correct.
* All Windows HP 2014.2.0.0 packages have been built without --enabled-split-objs, in deference to the GHC 7.8 FAQ
No, this shouldn't be needed. split-objs should work just fine on Windows; the FAQ was referencing the fact that *users* using split-objs in their Cabal configurations will probably get odd behavior (we don't encourage split-objs outside of the packages GHC ships). Sometimes bugs arise but these generally aren't high priority for arbitrary user code. (It will also hurt users since it will dramatically increase link time - it should only be used for GHC libraries!) If you have issues here, please let me know; it's a bug.
* Extra python, etc. bits included in the GHC 7.8.3 bindist for 64-bit Windows (GHC issue #9014) are not installed with Windows HP 2014.2.0.0. Is eliding them from the HP 2014.2.0.0 64-bit Windows installation safe and correct (i.e., are they truely not required)?
Hmmmm, that seems like a total oversight on my part! Yes, deleting them should be fine. Upon review, I think they're just artifacts of our 64 bit MinGW distribution.
* Missing src/html in GHC packages were worked around by replacing the entire GHC package doc tree of html files with the contents of the "Standard Libraries" tarball (but not for the two packages which are not built for Windows, terminfo and unix). Is this valid to do? Any issues might arise? * ref: http://www.haskell.org/ghc/docs/latest/libraries.html.tar.bz2
This should be just fine.
Thanks for any advice on these. I do want to make the Windows HP 2014.2.0.0 be as good as it can be.
Randy
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/
participants (4)
-
Austin Seipp
-
Mark Lentczner
-
Mikhail Glushenkov
-
Sven Panne