Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Register
  • Sign in
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
    • Locked files
  • Issues 5.5k
    • Issues 5.5k
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 631
    • Merge requests 631
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
    • Test cases
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and registries
    • Model experiments
  • Analytics
    • Analytics
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell CompilerGlasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #7072

GHC interpreter does not find stat64 symbol on Linux

Mailing list discussion available at: http://www.haskell.org/pipermail/haskell-cafe/2012-July/102253.html. 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);
	printf("Done\n");
}

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 (http://stackoverflow.com/questions/5478780/c-and-ld-preload-open-and-open64-calls-intercepted-but-not-stat64) 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 https://github.com/yesodweb/persistent/commit/d7daf0b2fa401fd97ef62e4e74228146d15d8601). 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.

Trac metadata
Trac field Value
Version 7.4.2
Type Bug
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component GHCi
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking