On Wed, Jul 11, 2012 at 9:55 PM, Bardur Arantsson <spam@scientician.net> wrote:

On 07/11/2012 05:12 PM, Michael Snoyman wrote:
>
> Thanks for the feedback. However, looking at sqlite3.c, I see the
> necessary #include statements:
>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <unistd.h>
>
> I'm confident that none of my code is making calls to stat/stat64 via
> the FFI. In case it makes a difference, this problem also disappears
> if I compile the library against the system copy of sqlite3 instead of
> using the C source.

You may need some extra defines, see the comments in "man stat64".

Regards,


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

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