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.
pgpFjqMeqMQZk.pgp
Description: PGP signature
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe