[Haskell-cafe] ghci and TH cannot: unknown symbol `stat64`

[Michael Snoyman]

On Thu, Jul 12, 2012 at 7:30 PM, Tristan Ravitch <travitch at 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" <travitch at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120713/bc15f843/attachment.htm>