<div dir="ltr"><br><br><div class="gmail_quote">On Thu, Jul 12, 2012 at 7:30 PM, Tristan Ravitch <span dir="ltr"><<a href="mailto:travitch@cs.wisc.edu" target="_blank">travitch@cs.wisc.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Thu, Jul 12, 2012 at 07:20:39PM +0300, Michael Snoyman wrote:<br>
> On Jul 12, 2012 7:13 PM, "Tristan Ravitch" <<a href="mailto:travitch@cs.wisc.edu">travitch@cs.wisc.edu</a>> wrote:<br>
> ><br>
> > On Thu, Jul 12, 2012 at 11:07:05AM -0500, Tristan Ravitch wrote:<br>
> > > Are you trying this on a 32 bit system? And when you compiled that C<br>
> > > program, did you try to add<br>
> > ><br>
> > > -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE<br>
> > ><br>
> > > to the compile command? When I define those the resulting object file<br>
> > > from your example correctly references stat64 instead of stat.<br>
> ><br>
> > Er sorry, saw your earlier email now. Could this be a mismatch<br>
> > between how your sqlite.so is compiled and how the cbits in<br>
> > persistent-sqlite are compiled, particularly with largefile support?<br>
><br>
> I don't think so. The test case I put together had nothing to do with<br>
> sqlite. Also, persistent-sqlite will either use sqlite.so _or_ the included<br>
> sqlite3.c file (based on a compile-time flag). The former works perfectly,<br>
> only the latter causes problems.<br>
><br>
> Michael<br>
<br>
</div></div>I was looking at the symbols in libc and noticed that it doesn't<br>
actually export stat64/stat, so that would explain something at least.<br>
I think your idea about the switch to function pointers versus direct<br>
calls is probably right - the linker probably does some rewriting of<br>
calls to stat into __fxstat and company, but for some reason doesn't<br>
handle references to function pointers.<br>
<br>
I also ran across this stackoverflow post that mentions something<br>
similar:<br>
<br>
<a href="http://stackoverflow.com/questions/5478780/c-and-ld-preload-open-and-open64-calls-intercepted-but-not-stat64" target="_blank">http://stackoverflow.com/questions/5478780/c-and-ld-preload-open-and-open64-calls-intercepted-but-not-stat64</a><br>
<br>
So stat64 is actually special and in this libc_nonshared.a library (it<br>
is on my system at least). It would be ugly to have to link that<br>
manually - not sure what the right answer is, but at least this might<br>
explain it.<br>
</blockquote></div><br><div>That's a great find, and it really explains a lot. It seems then that:</div><div><br></div><div>* GNU ld has some black magic do know about the stat/stat64 hack.</div><div>* Compiling via GHC just uses GNU ld, which is able to make the hack work.</div>
<div>* Interpreting with GHC doesn't get to take advantage of GNU ld's hack.</div><div><br></div><div>I've opened a trac ticket[1] for this issue, thank you very much for the help!</div><div><br></div><div>Michael</div>
<div><br></div><div>[1] <a href="http://hackage.haskell.org/trac/ghc/ticket/7072">http://hackage.haskell.org/trac/ghc/ticket/7072</a></div></div>