<div dir="ltr"><br><br><div class="gmail_quote">On Thu, Jul 12, 2012 at 6:29 PM, Michael Snoyman <span dir="ltr"><<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div class="h5"><br><br><div class="gmail_quote">On Wed, Jul 11, 2012 at 9:55 PM, Bardur Arantsson <span dir="ltr"><<a href="mailto:spam@scientician.net" target="_blank">spam@scientician.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On 07/11/2012 05:12 PM, Michael Snoyman wrote:<br>
><br>
> Thanks for the feedback. However, looking at sqlite3.c, I see the<br>
> necessary #include statements:<br>
><br>
> #include <sys/types.h><br>
> #include <sys/stat.h><br>
> #include <unistd.h><br>
><br>
> I'm confident that none of my code is making calls to stat/stat64 via<br>
> the FFI. In case it makes a difference, this problem also disappears<br>
> if I compile the library against the system copy of sqlite3 instead of<br>
> using the C source.<br>
<br>
</div>You may need some extra defines, see the comments in "man stat64".<br>
<br>
Regards,<br>
<br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div><br></div></div><div>I've come up with a minimal example that demonstrates this problem. The crux of the matter is the following C code:</div><div><br></div><div><div class="im"><div> #include <sys/types.h></div>
<div>
#include <sys/stat.h></div><div> #include <unistd.h></div></div><div> #include <stdio.h></div><div> </div><div> typedef int stat_func(const char*, struct stat*);</div><div> </div><div>
stat_func *foo = &stat;</div>
<div> </div><div> void stat_test(void)</div><div> {</div><div> <span style="white-space:pre-wrap"> </span>struct stat buf;</div><div> </div><div> <span style="white-space:pre-wrap"> </span>printf("About to stat-test.c\n");</div>
<div> <span style="white-space:pre-wrap"> </span>foo("stat-test.c", &buf);</div><div> <span style="white-space:pre-wrap"> </span>printf("Done\n");</div><div>
}</div></div><div><br></div><div>As you can see, all of the include statements are present as necessary. The code compiles just fine with -Wall -Werror. And when you compile the Haskell code as well, everything works just fine. But if you follow these steps, you can reproduce the error I saw:</div>
<div><br></div><div>* Unpack the attached tarball</div><div>* `cabal install` in that folder</div><div>* `runghc main.hs` from the `exe` folder</div><div><br></div><div>On my system at least, I get:</div><div><br></div><div>
<div> main.hs: /home/ubuntu/.cabal/lib/stat-test-0.1.0.0/ghc-7.4.1/HSstat-test-0.1.0.0.o: unknown symbol `stat'</div><div> main.hs: main.hs: unable to load package `stat-test-0.1.0.0'</div></div><div><br></div>
<div>One thing I noticed is that I needed to use a function pointer to trigger the bug. When I called `stat` directly the in stat_test function, gcc automatically inlined the call, so that the disassessmbled code just showed a `moveq` (i.e., it's making the system call directly). But using a function pointer, we're avoiding the inlining. I believe this is why this issue only came up with the sqlite3 upgrade: previous versions did not use a function pointer, but rather hard-coded in how to make a stat call.</div>
<div><br></div><div>Does this expose any other possibilities?</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Michael</div></font></span></div>
</blockquote></div><br><div>Actually, I just came up with a workaround: declare some local wrappers to the stat and fstat functions, and use those in place of stat and fstat in the rest of the code. You can see the change here[1].</div>
<div><br></div><div>Obviously this is a hack, not a real fix. At this point it looks like a GHC bug to me. Does anything think otherwise? If not, I'll open a ticket.</div><div><br></div><div>Michael</div><div><br></div>
<div>[1] <a href="https://github.com/yesodweb/persistent/commit/d7daf0b2fa401fd97ef62e4e74228146d15d8601">https://github.com/yesodweb/persistent/commit/d7daf0b2fa401fd97ef62e4e74228146d15d8601</a></div></div>