[Haskell-cafe] ghci and TH cannot: unknown symbol `stat64`
michael at snoyman.com
Fri Jul 13 11:24:00 CEST 2012
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
> > > > 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
> > sqlite3.c file (based on a compile-time flag). The former works
> > 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
> 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 for this issue, thank you very much for the
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe