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

On Thu, Jul 12, 2012 at 7:30 PM, Tristan Ravitch wrote:

...

On Jul 12, 2012 7:13 PM, "Tristan Ravitch" 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

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

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