On Thu, Jul 12, 2012 at 07:20:39PM +0300, Michael Snoyman wrote:
> On Jul 12, 2012 7:13 PM, "Tristan Ravitch" <travitch@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.