On Thu, Jul 12, 2012 at 7:07 PM, Tristan Ravitch <travi...@cs.wisc.edu>wrote:
> On Thu, Jul 12, 2012 at 06:29:41PM +0300, Michael Snoyman wrote: > > I've come up with a minimal example that demonstrates this problem. The > > crux of the matter is the following C code: > > > > #include <sys/types.h> > > #include <sys/stat.h> > > #include <unistd.h> > > #include <stdio.h> > > > > typedef int stat_func(const char*, struct stat*); > > > > stat_func *foo = &stat; > > > > void stat_test(void) > > { > > struct stat buf; > > > > printf("About to stat-test.c\n"); > > foo("stat-test.c", &buf); > > printf("Done\n"); > > } > > > > As you can see, all of the include statements are present as necessary. > The > > code compiles just fine with -Wall -Werror. And when you compile the > > Haskell code as well, everything works just fine. But if you follow these > > steps, you can reproduce the error I saw: > > > > * Unpack the attached tarball > > * `cabal install` in that folder > > * `runghc main.hs` from the `exe` folder > > > > On my system at least, I get: > > > > main.hs: > > > /home/ubuntu/.cabal/lib/stat-test-0.1.0.0/ghc-7.4.1/HSstat-test-0.1.0.0.o: > > unknown symbol `stat' > > main.hs: main.hs: unable to load package `stat-test-0.1.0.0' > > > > One thing I noticed is that I needed to use a function pointer to trigger > > the bug. When I called `stat` directly the in stat_test function, gcc > > automatically inlined the call, so that the disassessmbled code just > showed > > a `moveq` (i.e., it's making the system call directly). But using a > > function pointer, we're avoiding the inlining. I believe this is why this > > issue only came up with the sqlite3 upgrade: previous versions did not > use > > a function pointer, but rather hard-coded in how to make a stat call. > > > > Does this expose any other possibilities? > > > > Michael > > 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. > I'm compiling on a 64 bit system. If I add those definitions, the program uses stat64 instead, but the only difference is that runghc now prints: main.hs: /home/ubuntu/.cabal/lib/stat-test-0.1.0.0/ghc-7.4.1/HSstat-test-0.1.0.0.o: unknown symbol `stat64' main.hs: main.hs: unable to load package `stat-test-0.1.0.0' In other words, it's not the symbol that the object file is referencing (stat vs stat64) that's the problem: runghc is not able to resolve either one. Michael
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe