You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: atom.xml
+18-1
Original file line number
Diff line number
Diff line change
@@ -48,14 +48,31 @@
48
48
...
49
49
</code></pre>
50
50
<p>Yeah, that will work. Using the cross compiler above, and the ARM Gentoo environment set up below I was able to compile my program just fine using:</p>
<p>Which is <em>AWESOME</em> because the native compiler is <em>so</em> much faster than the one emulated with QEMU. This is not without caveats. For instance when compiling with multiple jobs it took forever and then ran out of memory, setting <code>-j1</code> with <code>cabal install</code> fixed this particular issue.</p>
56
56
<p>A bigger problem is that there appears to be issues with the C FFI. I’m not yet sure how this works, but when I try to run an ARM binary which uses JuicyPixels to write a PNG (which relies upon zlib), I get this error:</p>
<p>but otherwise this works surprisingly well.</p>
59
+
<p>After a bit of digging I have found that this error comes from <a href="https://github.com/haskell/zlib/blob/85f2d95396ff884ff22af62e5e0d6029c789db63/Codec/Compression/Zlib/Stream.hsc#L549">here</a>, and since we have got an actual failure, it’s probably from calling the <code>failIfError</code> function. That means our issue is from <a href="https://github.com/haskell/zlib/blob/85f2d95396ff884ff22af62e5e0d6029c789db63/Codec/Compression/Zlib/Stream.hsc#L953">here</a>.</p>
60
+
<p>I have checked the zlib version on all of my environments, and the version is 1.2.8 everywhere. So the <em>version</em> isn’t the issue. In fact if we look at the <a href="https://github.com/madler/zlib/blob/e8fee0ea7bf62e595bd5518b7b22e3e16397278c/deflate.c#L233">code</a> for <code>c_deflateInit2_</code> we’ll notice that it’s only checking the first version number anyway:</p>
<p>But there’s our problem. The size of our <code>z_stream</code> must differ somehow. If we check the <a href="https://github.com/haskell/zlib/blob/85f2d95396ff884ff22af62e5e0d6029c789db63/Codec/Compression/Zlib/Stream.hsc#L1039">Haskell Zlib library</a> we notice the following:</p>
c_deflateInit2_ z a b c d e versionStr (<span class="fu">#</span>{const sizeof(z_stream)}<span class="ot"> ::</span> <span class="dt">CInt</span>)</code></pre></div>
72
+
<p>I’m on an x86_64 machine, so it’s pretty much guaranteed that the <code>z_stream</code> structure on my machine differs in size to the one on the 32 bit ARM machines. This should be processed by <code>hsc2hs</code>, so that’s where the issue is. I need to be running an <code>hsc2hs</code> that targets ARM, not my native one. I had an <code>arm-unknown-linux-gnueabihf-hsc2hs</code>, but it seemed to loop forever, as did the <code>hsc2hs</code> from my chroot (but not when running it in my chroot). So that’s no good either.</p>
73
+
<p>I can pass <code>hsc2hs</code> options with cabal, however, which means I can tell the native one to compile using a <code>gcc</code> cross compiler, and you know what… It takes a linker too, so let’s throw that in for good measure too!</p>
<p>Unfortunately that still doesn’t work! We’re on the right track, but not quite there yet.</p>
59
76
<h1 id="running-on-the-raspberry-pi">Running on the Raspberry Pi</h1>
60
77
<p>Raspbian has an old version of GHC in its repos, GHC 7.6.3, which works with simple pieces of code. For instance “Hello, World!” might compile and run perfectly well. However, my small image processing program encountered nasty, randomly changing, run time errors, and segmentation faults. Sometimes, if the stars aligned, the program would run to completion producing correct results, other times it seemed to loop forever. This is not good. One such error that I received was:</p>
61
78
<pre><code>allocGroup: free list corrupted</code></pre>
Copy file name to clipboardexpand all lines: posts/2015-12-15-arm.html
+18-1
Original file line number
Diff line number
Diff line change
@@ -83,14 +83,31 @@ <h2 id="cross-compilation-with-qemu">Cross-Compilation with QEMU</h2>
83
83
...
84
84
</code></pre>
85
85
<p>Yeah, that will work. Using the cross compiler above, and the ARM Gentoo environment set up below I was able to compile my program just fine using:</p>
<p>Which is <em>AWESOME</em> because the native compiler is <em>so</em> much faster than the one emulated with QEMU. This is not without caveats. For instance when compiling with multiple jobs it took forever and then ran out of memory, setting <code>-j1</code> with <code>cabal install</code> fixed this particular issue.</p>
91
91
<p>A bigger problem is that there appears to be issues with the C FFI. I’m not yet sure how this works, but when I try to run an ARM binary which uses JuicyPixels to write a PNG (which relies upon zlib), I get this error:</p>
<p>but otherwise this works surprisingly well.</p>
94
+
<p>After a bit of digging I have found that this error comes from <a href="https://github.com/haskell/zlib/blob/85f2d95396ff884ff22af62e5e0d6029c789db63/Codec/Compression/Zlib/Stream.hsc#L549">here</a>, and since we have got an actual failure, it’s probably from calling the <code>failIfError</code> function. That means our issue is from <a href="https://github.com/haskell/zlib/blob/85f2d95396ff884ff22af62e5e0d6029c789db63/Codec/Compression/Zlib/Stream.hsc#L953">here</a>.</p>
95
+
<p>I have checked the zlib version on all of my environments, and the version is 1.2.8 everywhere. So the <em>version</em> isn’t the issue. In fact if we look at the <a href="https://github.com/madler/zlib/blob/e8fee0ea7bf62e595bd5518b7b22e3e16397278c/deflate.c#L233">code</a> for <code>c_deflateInit2_</code> we’ll notice that it’s only checking the first version number anyway:</p>
<p>But there’s our problem. The size of our <code>z_stream</code> must differ somehow. If we check the <a href="https://github.com/haskell/zlib/blob/85f2d95396ff884ff22af62e5e0d6029c789db63/Codec/Compression/Zlib/Stream.hsc#L1039">Haskell Zlib library</a> we notice the following:</p>
c_deflateInit2_ z a b c d e versionStr (<span class="fu">#</span>{const sizeof(z_stream)}<span class="ot"> ::</span> <span class="dt">CInt</span>)</code></pre></div>
107
+
<p>I’m on an x86_64 machine, so it’s pretty much guaranteed that the <code>z_stream</code> structure on my machine differs in size to the one on the 32 bit ARM machines. This should be processed by <code>hsc2hs</code>, so that’s where the issue is. I need to be running an <code>hsc2hs</code> that targets ARM, not my native one. I had an <code>arm-unknown-linux-gnueabihf-hsc2hs</code>, but it seemed to loop forever, as did the <code>hsc2hs</code> from my chroot (but not when running it in my chroot). So that’s no good either.</p>
108
+
<p>I can pass <code>hsc2hs</code> options with cabal, however, which means I can tell the native one to compile using a <code>gcc</code> cross compiler, and you know what… It takes a linker too, so let’s throw that in for good measure too!</p>
<p>Unfortunately that still doesn’t work! We’re on the right track, but not quite there yet.</p>
94
111
<h1 id="running-on-the-raspberry-pi">Running on the Raspberry Pi</h1>
95
112
<p>Raspbian has an old version of GHC in its repos, GHC 7.6.3, which works with simple pieces of code. For instance “Hello, World!” might compile and run perfectly well. However, my small image processing program encountered nasty, randomly changing, run time errors, and segmentation faults. Sometimes, if the stars aligned, the program would run to completion producing correct results, other times it seemed to loop forever. This is not good. One such error that I received was:</p>
96
113
<pre><code>allocGroup: free list corrupted</code></pre>
Copy file name to clipboardexpand all lines: rss.xml
+18-1
Original file line number
Diff line number
Diff line change
@@ -44,14 +44,31 @@
44
44
...
45
45
</code></pre>
46
46
<p>Yeah, that will work. Using the cross compiler above, and the ARM Gentoo environment set up below I was able to compile my program just fine using:</p>
<p>Which is <em>AWESOME</em> because the native compiler is <em>so</em> much faster than the one emulated with QEMU. This is not without caveats. For instance when compiling with multiple jobs it took forever and then ran out of memory, setting <code>-j1</code> with <code>cabal install</code> fixed this particular issue.</p>
52
52
<p>A bigger problem is that there appears to be issues with the C FFI. I’m not yet sure how this works, but when I try to run an ARM binary which uses JuicyPixels to write a PNG (which relies upon zlib), I get this error:</p>
<p>but otherwise this works surprisingly well.</p>
55
+
<p>After a bit of digging I have found that this error comes from <a href="https://github.com/haskell/zlib/blob/85f2d95396ff884ff22af62e5e0d6029c789db63/Codec/Compression/Zlib/Stream.hsc#L549">here</a>, and since we have got an actual failure, it’s probably from calling the <code>failIfError</code> function. That means our issue is from <a href="https://github.com/haskell/zlib/blob/85f2d95396ff884ff22af62e5e0d6029c789db63/Codec/Compression/Zlib/Stream.hsc#L953">here</a>.</p>
56
+
<p>I have checked the zlib version on all of my environments, and the version is 1.2.8 everywhere. So the <em>version</em> isn’t the issue. In fact if we look at the <a href="https://github.com/madler/zlib/blob/e8fee0ea7bf62e595bd5518b7b22e3e16397278c/deflate.c#L233">code</a> for <code>c_deflateInit2_</code> we’ll notice that it’s only checking the first version number anyway:</p>
<p>But there’s our problem. The size of our <code>z_stream</code> must differ somehow. If we check the <a href="https://github.com/haskell/zlib/blob/85f2d95396ff884ff22af62e5e0d6029c789db63/Codec/Compression/Zlib/Stream.hsc#L1039">Haskell Zlib library</a> we notice the following:</p>
c_deflateInit2_ z a b c d e versionStr (<span class="fu">#</span>{const sizeof(z_stream)}<span class="ot"> ::</span> <span class="dt">CInt</span>)</code></pre></div>
68
+
<p>I’m on an x86_64 machine, so it’s pretty much guaranteed that the <code>z_stream</code> structure on my machine differs in size to the one on the 32 bit ARM machines. This should be processed by <code>hsc2hs</code>, so that’s where the issue is. I need to be running an <code>hsc2hs</code> that targets ARM, not my native one. I had an <code>arm-unknown-linux-gnueabihf-hsc2hs</code>, but it seemed to loop forever, as did the <code>hsc2hs</code> from my chroot (but not when running it in my chroot). So that’s no good either.</p>
69
+
<p>I can pass <code>hsc2hs</code> options with cabal, however, which means I can tell the native one to compile using a <code>gcc</code> cross compiler, and you know what… It takes a linker too, so let’s throw that in for good measure too!</p>
<p>Unfortunately that still doesn’t work! We’re on the right track, but not quite there yet.</p>
55
72
<h1 id="running-on-the-raspberry-pi">Running on the Raspberry Pi</h1>
56
73
<p>Raspbian has an old version of GHC in its repos, GHC 7.6.3, which works with simple pieces of code. For instance “Hello, World!” might compile and run perfectly well. However, my small image processing program encountered nasty, randomly changing, run time errors, and segmentation faults. Sometimes, if the stars aligned, the program would run to completion producing correct results, other times it seemed to loop forever. This is not good. One such error that I received was:</p>
57
74
<pre><code>allocGroup: free list corrupted</code></pre>
0 commit comments