<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1256">
<meta name="generator" content="Windows Mail 17.5.9600.20315">
<style data-externalstyle="true"><!--
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
}
p.MsoNormal, li.MsoNormal, div.MsoNormal {
margin:0in;
margin-bottom:.0001pt;
}
p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParagraphCxSpFirst, 
p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle, 
p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
line-height:115%;
}
--></style>
</head>
<body dir="ltr">
<div data-externalstyle="false" dir="ltr" style="font-family: 'Calibri', 'Segoe UI', 'Meiryo', 'Microsoft YaHei UI', 'Microsoft JhengHei UI', 'Malgun Gothic', 'sans-serif';font-size:12pt;">
<div>
<div>Because I think it’s going to be an organizational issue and a duplication of effort if GHC is built one way but the future direction of LLVM is another.</div>
<div><br>
</div>
<div>Imagine if GCC started developing a new engine and it didn’t work with one of the biggest, most regular consumers of GCC. Say, the Linux kernel, or itself. At first, the situation is optimistic - if this engine doesn’t work for the project that has the
 smartest, brightest GCC hackers potentially looking at it, then it should fix itself soon enough. Suppose the situation lingers though, and continues for months without fix. The new GCC backend starts to become the default, and the community around GCC advocates
 for end-users to use it to optimize code for their projects and it even becomes the default for some platforms, such as ARM.</div>
<div><br>
</div>
<div>What I’ve described is analogous to the GHC situation - and the result is that GHC isn’t self-hosting on some platforms and the inertia that used to be behind the LLVM backend seems to have stagnated. Whereas LLVM used to be the “new hotness”, I’ve noticed
 that issues like Trac #7787 no longer have a lot of eyes on them and externally it seems like GHC has accepted a bifurcated approach for development.
</div>
<div><br>
</div>
<div>I dramatize the situation above, but there’s some truth to it. The LLVM backend needs some care and attention and if the majority of GHC devs can’t build GHC with LLVM, then that means the smartest, brightest GHC hackers won’t have their attention turned
 toward fixing those problems. If a patch to GHC-HEAD broke compilation for every backend, it would be fixed in short order. If a new version of GCC did not work with GHC, I can imagine it would be only hours before the first patches came in resolving the issue.
 On OS X Mavericks, an incompatibility with GHC has led to a swift reaction and strong support for resolving platform issues. The attention to the LLVM backend is visibly smaller, but I don’t know enough about the people working on GHC to know if it is actually
 smaller.</div>
<div><br>
</div>
<div>The way I am trying to change this is by making it easier for people to start using GHC (by putting images on Docker.io) and, in the process, learning about GHC’s build process and trying to make things work for my own projects. The Docker image allows
 anyone with a Linux kernel to build and play with GHC HEAD. The information about building GHC yourself is difficult to approach and I found it hard to get started, and I want to improve that too, so I’m learning and asking questions.</div>
</div>
<div><br>
</div>
<div style="padding-top: 5px; border-top-color: rgb(229, 229, 229); border-top-width: 1px; border-top-style: solid;">
<div><font face=" 'Calibri', 'Segoe UI', 'Meiryo', 'Microsoft YaHei UI', 'Microsoft JhengHei UI', 'Malgun Gothic', 'sans-serif'" style="line-height: 15pt; letter-spacing: 0.02em; font-family: "Calibri", "Segoe UI", "Meiryo", "Microsoft YaHei UI", "Microsoft JhengHei UI", "Malgun Gothic", "sans-serif"; font-size: 12pt;"><b>From:</b> <a href="mailto:carter.schonwald@gmail.com" target="_parent">Carter
 Schonwald</a><br>
<b>Sent:</b> ýWednesdayý, ýJanuaryý ý1ý, ý2014 ý5ý:ý54ý ýPM<br>
<b>To:</b> <a href="mailto:aaron@frieltek.com" target="_parent">Aaron Friel</a><br>
<b>Cc:</b> <a href="mailto:ghc-devs@haskell.org" target="_parent">ghc-devs@haskell.org</a></font></div>
</div>
<div><br>
</div>
<div dir="">
<div dir="ltr">7.8 should have working dylib support on the llvm backend. (i believe some of the relevant patches are in head already, though Ben Gamari can opine on that)
<div><br>
</div>
<div>why do you want ghc to be built with llvm? (i know i've tried myself in the past, and it should be doable with 7.8 using 7.8 soon too)</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Jan 1, 2014 at 5:38 PM, Aaron Friel <span dir="ltr">
<<a href="mailto:aaron@frieltek.com" target="_parent">aaron@frieltek.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">
<div dir="ltr">
<div style="font-family: "Calibri","Segoe UI","Meiryo","Microsoft YaHei UI","Microsoft JhengHei UI","Malgun Gothic","sans-serif"; font-size: 12pt;" dir="ltr">
<div>Replying to include the email list. You’re right, the llvm backend and the gmp licensing issues are orthogonal - or should be. The problem is I get build errors when trying to build GHC with LLVM and dynamic libraries.</div>
<div><br>
</div>
<div>The result is that I get a few different choices when producing a platform image for development, with some uncomfortable tradeoffs:</div>
<div><br>
</div>
<ol style="padding-top: 0px; padding-bottom: 0px; margin-top: 0px; margin-bottom: 0px; list-style-type: decimal;">
<li style="font-family: "Color Emoji","Calibri","Segoe UI","Meiryo","Microsoft YaHei UI","Microsoft JhengHei UI","Malgun Gothic","sans-serif"; font-size: 16px;">
<div>LLVM-built GHC, dynamic libs - doesn’t build.</div>
</li><li style="font-family: "Color Emoji","Calibri","Segoe UI","Meiryo","Microsoft YaHei UI","Microsoft JhengHei UI","Malgun Gothic","sans-serif"; font-size: 16px;">
<div>LLVM-built GHC, static libs - potential licensing oddities with me shipping a statically linked ghc binary that is now gpled. I am not a lawyer, but the situation makes me uncomfortable.</div>
</li><li style="font-family: "Color Emoji","Calibri","Segoe UI","Meiryo","Microsoft YaHei UI","Microsoft JhengHei UI","Malgun Gothic","sans-serif"; font-size: 16px;">
<div>GCC/ASM-built GHC, dynamic libs - this is the *standard* for most platforms shipping ghc binaries, but it means that one of the biggest and most critical users of the LLVM backend is neglecting it. It also bifurcates development resources for GHC. Optimization
 work is duplicated and already devs are getting into the uncomfortable position of suggesting to users that they should trust GHC to build your programs in a particular way, but not itself.</div>
</li><li style="font-family: "Color Emoji","Calibri","Segoe UI","Meiryo","Microsoft YaHei UI","Microsoft JhengHei UI","Malgun Gothic","sans-serif"; font-size: 16px;">
<div>GCC/ASM-built GHC, static libs - worst of all possible worlds.</div>
</li></ol>
<div style="font-family: "Color Emoji","Calibri","Segoe UI","Meiryo","Microsoft YaHei UI","Microsoft JhengHei UI","Malgun Gothic","sans-serif"; font-size: 16px;">
<br>
</div>
<div style="font-family: "Color Emoji","Calibri","Segoe UI","Meiryo","Microsoft YaHei UI","Microsoft JhengHei UI","Malgun Gothic","sans-serif"; font-size: 16px;">
Because of this, the libgmp and llvm-backend issues aren’t entirely orthogonal. Trac ticket #7885 is exactly the issue I get when trying to compile #1.</div>
<div><br>
</div>
<div style="padding-top: 5px; border-top-color: rgb(229, 229, 229); border-top-width: 1px; border-top-style: solid;">
<div><font face=" 'Calibri', 'Segoe UI', 'Meiryo', 'Microsoft YaHei UI', 'Microsoft JhengHei UI', 'Malgun Gothic', 'sans-serif'" style="line-height: 15pt; letter-spacing: 0.02em; font-family: "Calibri","Segoe UI","Meiryo","Microsoft YaHei UI","Microsoft JhengHei UI","Malgun Gothic","sans-serif"; font-size: 12pt;"><b>From:</b> <a href="mailto:carter.schonwald@gmail.com" target="_parent">Carter
 Schonwald</a><br>
<b>Sent:</b> ýMondayý, ýDecemberý ý30ý, ý2013 ý1ý:ý05ý ýPM<br>
<b>To:</b> <a href="mailto:aaron@frieltek.com" target="_parent">Aaron Friel</a></font></div>
</div>
<div>
<div class="h5">
<div><br>
</div>
<div dir="auto">
<div>Good question but you forgot to email the mailing list too :-)</div>
<div><br>
</div>
<div>Using llvm has nothing to do with Gmp. Use the native code gen (it's simper) and integer-simple. </div>
<div><br>
</div>
<div>That said, standard ghc dylinks to a system copy of Gmp anyways (I think ). Building ghc as a Dylib is orthogonal. <br>
<br>
-Carter</div>
<div><br>
On Dec 30, 2013, at 1:58 PM, Aaron Friel <<a href="mailto:aaron@frieltek.com" target="_parent">aaron@frieltek.com</a>> wrote:<br>
<br>
</div>
<blockquote style="margin-top: 0px; margin-bottom: 0px;">
<div>
<div style="font-family: "Calibri","Segoe UI","Meiryo","Microsoft YaHei UI","Microsoft JhengHei UI","Malgun Gothic","sans-serif"; font-size: 12pt;" dir="ltr">
<div>Excellent research - I’m curious if this is the right thread to inquire about the status of trying to link GHC itself dynamically.</div>
<div><br>
</div>
<div>I’ve been attempting to do so with various LLVM versions (3.2, 3.3, 3.4) using snapshot builds of GHC (within the past week) from git, and I hit ticket #7885 [<a href="https://ghc.haskell.org/trac/ghc/ticket/7885" target="_parent">https://ghc.haskell.org/trac/ghc/ticket/7885</a>]
 every time (even the exact same error message).</div>
<div><br>
</div>
<div>I’m interested in dynamically linking GHC with LLVM to avoid the entanglement with libgmp’s license.
</div>
<div><br>
</div>
<div>If this is the wrong thread or if I should reply instead to the trac item, please let me know.<br>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</body>
</html>