Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
GHC
GHC
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,262
    • Issues 4,262
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 419
    • Merge Requests 419
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #2979

Closed
Open
Opened Jan 25, 2009 by duncan@trac-duncan

better support for FFI C wrappers for macros in system headers

Often C functions get defined via macros on some systems. For example iconv gets munged and renamed by some silly macros on OSX. This messes up the iconv binding package (and haskeline which currently directly ffi imports iconv rather than using the Haskell iconv package).

Actually making wrapper functions is harder than it should be. For one thing one has to pick a single name for the wrapper function and this then prevents loading multiple versions of a Haskell package because their C symbols will clash. We have similar problems for C snippets in other packages like bytestring, so it's not constraint to FFI wrappers.

We should think about how to make this easier. We should think about where the best place to put improvements eg ghc, cabal, c2hs or hsc2hs.

Perhaps just a way to compile versioned C function names using a CPP define for the current package name and version. Eg in the .c file:

int HS_VERSIONED_SYMBOL(foo_wrapper) (int blah) {
  ...
}

And similar in the .hs file where we ffi import it.

Trac metadata
Trac field Value
Version 6.10.1
Type FeatureRequest
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture
Assignee
Assign to
7.6.1
Milestone
7.6.1
Assign milestone
Time tracking
None
Due date
None
Reference: ghc/ghc#2979