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