Opened 7 years ago

Closed 4 years ago

Last modified 4 years ago

#7072 closed bug (fixed)

GHC interpreter does not find stat64 symbol on Linux

Reported by: snoyberg Owned by:
Priority: normal Milestone: 7.8.1
Component: GHCi Version: 7.4.2
Keywords: Cc: hvr
Operating System: Linux Architecture: x86_64 (amd64)
Type of failure: GHCi crash Test Case:
Blocked By: #3658 Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


Mailing list discussion available at: The issue is that, when using runghc against a library using the sqlite3 C library (persistent-sqlite), the stat64 symbol is not resolved. After some research, I came up with the following minimal reproducing 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);

When using stat directly, gcc inlines the call and produces assembly which simply makes a system call, thereby avoiding the need for the stat symbol. However, when using a function pointer (as sqlite3 does), the symbol is retained, and then runghc does not resolve it.

In the linked mailing list discussion, Tristan Ravitch found a Stack Overflow thread ( which explains that the GNU linker has special handling for the stat, stat64, and a few other library functions. glibc itself does not provide those symbols directly, relying on the linker to fix the references. (I could not find reference to this in any official documentation.)

As a workaround, I declared some local functions which call stat and stat64 (patch available at So there is a workaround available, and therefore this isn't high priority for me. But I do think it's worth some kind of fix.

Without having a good understanding of the GHC interpreter, my guess would be that it needs to replicate the stat/stat64/etc hack that the GNU linker is performing. Of course, this guess may be incorrect.

Tested on Ubuntu 12.04 64-bit, though I believe it will affect any recent version of Linux, whether 32- or 64-bit.

Attachments (1)

stat-test- (764 bytes) - added by snoyberg 7 years ago.
cabal package with executable demonstrating described bug.

Download all attachments as: .zip

Change History (6)

Changed 7 years ago by snoyberg

Attachment: stat-test- added

cabal package with executable demonstrating described bug.

comment:1 Changed 6 years ago by igloo

Blocked By: 3658 added

comment:2 Changed 6 years ago by igloo

difficulty: Unknown
Milestone: 7.8.1

Thanks for the report. I get this:

ghc --make Setup
./Setup configure
./Setup build
./Setup register --inplace
cd exe
ghci main.hs
GHCi, version 7.7.20121020:  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main             ( main.hs, interpreted )
Ok, modules loaded: Main.
*Main> main
Loading package stat-test- ... linking ... <interactive>: /home/ian/work/ghc/tmp/7072/stat-test- unknown symbol `stat'
ghc-stage2: unable to load package `stat-test-'

but with dynamic-by-default:

*Main> main
Loading package stat-test- ... linking ... done.
About to stat-test.c

so this will be fixed when we move to dynamic-by-default.

comment:3 Changed 5 years ago by thoughtpolice


Moving to 7.10.1.

comment:4 Changed 4 years ago by thomie

Cc: hvr added
Milestone: 7.10.1
Resolution: fixed
Status: newclosed

GHCi on Linux has been using the system linker since 7.8.1, see DynamicGhcPrograms, so this is no longer an issue.

comment:5 Changed 4 years ago by hvr

Milestone: 7.8.1
Note: See TracTickets for help on using tickets.