Opened 12 months ago

Last modified 3 days ago

#9348 new bug

"Symbol not found" when using a shared library

Reported by: alex.davis Owned by: simonmar
Priority: normal Milestone:
Component: Documentation Version: 7.8.3
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: x86
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description (last modified by alex.davis)

I'm trying to make a shared library from a simple program. It works fine on my Windows box, but gives an error on Mac OS X. Furthermore, the error seems to be generated from one of GHC's shared libraries.

What happens is this. I compile my shared library with GHC, which works fine. But when I try to use it from another program (specifically, R), I get an error message containing the following:
Symbol not found: _stg_IND_STATIC_info

Referenced from: /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc-prim-0.3.1.0-ghc7.8.3.dylib
Expected in: flat namespace

in /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc-prim-0.3.1.0-ghc7.8.3.dylib

More details:
The program I'm trying to use is R. In R, you load a shared library with the command "dyn.load". When I try this, the command I use is "dyn.load('final.dylib')", and the full error message is what follows:
---
Error in dyn.load("final.dylib") :

unable to load shared object '/Users/alexanderdavis/Desktop/illustrate bug copy/final.dylib':
dlopen(/Users/alexanderdavis/Desktop/illustrate bug copy/final.dylib, 6): Symbol not found: _stg_IND_STATIC_info
Referenced from: /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc-prim-0.3.1.0-ghc7.8.3.dylib
Expected in: flat namespace

in /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc-prim-0.3.1.0-ghc7.8.3.dylib

---

As I said, I have done all of this with no trouble on Windows. I compiled into a DLL, loaded the program into R, and was able to use the functions in it. However, on Windows I was also using an older version of GHC, and may have used the Haskell Platform and thus had more libraries installed - I don't have the computer with me, so I'm not sure.

My Mac OS version is 10.9.4.

My R version is 3.0.2. When loaded, it displays "Platform: x86_64-apple-darwin10.8.0 (64-bit)", but Sys.getev("R_ARCH") returns the empty string.

Command used for compiler:
ghc --make -dynamic -fPIC -shared SumRoots.hs StartEnd.c -o final.dylib

The code is attached. It is from a blog post by Neil Mitchelll (author of HLint) about calling Haskell from R: http://neilmitchell.blogspot.com/2011/10/calling-haskell-from-r.html

Attachments (3)

SumRoots.hs (396 bytes) - added by alex.davis 12 months ago.
Simple Haskell program
StartEnd.c (246 bytes) - added by alex.davis 12 months ago.
C code to start the runtime environment
errorFromC.c (214 bytes) - added by alex.davis 12 months ago.

Download all attachments as: .zip

Change History (7)

Changed 12 months ago by alex.davis

Simple Haskell program

Changed 12 months ago by alex.davis

C code to start the runtime environment

comment:1 Changed 12 months ago by alex.davis

  • Description modified (diff)

comment:2 Changed 12 months ago by alex.davis

  • Description modified (diff)

Changed 12 months ago by alex.davis

comment:3 follow-up: Changed 12 months ago by alex.davis

Shea Levy figured out the problem and its solution.

First of all, its not a problem with R, you get the same error from C. I've attached Shea's C code, which I've titled "errorFromC.c". This code tries to load the Haskell shared library, which it assumes is named "test.dylib", and gives the same error as R.

Second, the problem is solved by adding to the compilation the flag "-lHSrts-ghc7.8.3". This links the Haskell runtime system to the resulting file.
(although, on my computer I still get errors due to the use if Int instead of CInt in the Haskell code. But the problem of not being able to access the Haskell code at all is solved.)

This represents a mismatch between the behavior of the compiler and its documentation. People looking to make shared libraries will read section 4.13.3 of the GHC user's guide. They will see "To build Haskell modules that export a C API into a shared library use the -dynamic, -fPIC and -shared flag". No mention of linking the runtime system. I'm not sure if this a problem with the compiler or the documentation, but either way it should be fixed.

comment:4 in reply to: ↑ 3 Changed 3 days ago by thomie

  • Cc simonmar removed
  • Component changed from Runtime System to Documentation
  • Operating System changed from MacOS X to Unknown/Multiple

Replying to alex.davis:

This represents a mismatch between the behavior of the compiler and its documentation. People looking to make shared libraries will read section 4.13.3 of the GHC user's guide. They will see "To build Haskell modules that export a C API into a shared library use the -dynamic, -fPIC and -shared flag". No mention of linking the runtime system.

The next sentence does say:

"As before, the -dynamic flag specifies that this library links against the shared library versions of the rts and base package."

And after that:

"In principle you can use -shared without -dynamic in the link step. That means to statically link the rts all the base libraries into your new shared library. This would make a very big, but standalone shared library. On most platforms however that would require all the static libraries to have been built with -fPIC so that the code is suitable to include into a shared library and we do not do that at the moment."

Improvements to the documentation are always welcome.

Note: See TracTickets for help on using tickets.