GHC does not care __RENAME macro

[iquiw]

Problem

GHC+FFI does not use correct symbol if __RENAME macro is used.

Background

NetBSD uses __RENAME macro to solve compatibility issue of different versioned shared library.

For example, the following line is in /usr/include/locale.h.

char            *setlocale(int, const char *) __RENAME(__setlocale_mb_len_max_32);

If setlocale() is called from C source that includes "locale.h", then it is linked to symbol __setlocale_mb_len_max_32 after compiled.

GHC (-fasm) does not do this.
If GHC option -fvia-C is specified, then correct symbol is used

Example

__RENAME(foo) is actually expanded as __asm("foo"). So the following codes simulate the problem.

rename.h

int foo() __asm("bar");

rename.c

int foo() { return 1; }
int bar() { return 2; }

main.hs

foreign import ccall unsafe "rename.h" foo :: IO Int

main = foo >>= print

(1) -fvia-C(OK)

$ ghc -fvia-C -ffi main.hs rename.c && ./a.out                
2                 

(2) -fasm (OK)

$ ghc -fasm -ffi main.hs rename.c && ./a.out  
1

[iquiw]

- (2) -fasm (OK) 
+ (2) -fasm (NG) 

[simonmar]

This is not a bug, as such - or rather, it's a bug in the via-C backend that it actually works when compiling with -fvia-C (we fixed this recently in HEAD). The FFI is defined to interface to the C ABI rather than the C API; it doesn't take account of CPP magic.

To work around this you typically need to call a C wrapper via the FFI rather than calling the C function directly. The C wrapper lives in a .c file and gets compiled by the C compiler. We have lots of these scattered about the libraries already.

[simonpj]

But Don Cave records in this email that the libraries we ship with GHC are missing some such wrappers. So really this is an open bug until someone adds the wrappers to the appropriate libraries. Thus I'm re-opening. (Re-close if I'm under a mis-apprehension.)

 http://www.haskell.org/pipermail/glasgow-haskell-users/2008-June/014871.html

Don can you tell us which are the offending libraries and C imports?

Simon

[simonmar]

Closing; if there is a need for wrappers in particular libraries then someone should open tickets for those. To help with the more general problem, I've created Task #2471.