add ability to version symbols .c for packages with C code

Let's consider an example:

We have a haskell package with some C code imported in haskell:

// a.h file
int get_something(void);

// a.c file
#include "a.h"
int get_something(void) { return 42; }

// M.hs file
module M where

foreign import ccall "a.h get_something" :: IO Int

The problem here is we can't mix that package with other packages having global 'get_something' symbol.

Sometimes it happens when a package copies part of implementation from another package with .c bits under different haskell namespace. Haskell parts would coexist freely, but not C symbols.

Would be great if ghc would export some unique package identifier in a way C code could attach it to all exported symbols making linking possible.

Something like that:

// a.h file
#include "HsFFI.h" /* #define FOR_HASKELL(__sym) package_id_##__sym */
int FOR_HASKELL(get_something)(void);

// a.c file
#include "a.h"
int FOR_HASKELL(get_something)(void) { return 42; }

// M.hs file
module M where

foreign import ccall-for-haskell "a.h get_something" :: IO Int

That way we explicitly mark symbol as inaccessible to external plain C code.

Trac metadata

Trac field	Value
Version	7.8.3
Type	FeatureRequest
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

mentioned in issue #9265 (closed)

changed weight to 5

added Tfeature request Trac import backpack labels

Fwiw, I'd rather have a macro for the .hs part as well than have yet another FFI calling convention. (it'd be useful in other cases as well, to have the ability to uniformly transform the ABI-level C symbol name; e.g. for GMP, all official function names are prefixed by __g prefix at the ABI level)

E.g. something like:

foreign import ccall C_PKG_NAME("a.h","get_something") :: IO Int

This will, however, require a better CPP than the current traditional CPP mode to work...

Yeah, it's just an idea of symbol mangling control.

Maybe macro introduction better be done on cabal's side?

Or a more automagic approach might be to use binutils to rename or hide C symbols.

duncan: the problem with a more magic approach is that mangling the symbols could break uses of dlopen in the compiled objects, since you have no idea if a string is referring to a specific symbol.

mentioned in issue #11748 (closed)

added Pnormal label