Undefined symbol error coming from shared, dynamic library.
Brandon Allbery
allbery.b at gmail.com
Sun Sep 11 17:58:15 CEST 2011
On Sun, Sep 11, 2011 at 10:56, Captain Freako <capn.freako at gmail.com> wrote:
> I can understand why I'd have to explicitly link against `libHSrts',
> since I'm asking ghc for a shared object library and not an
> executable. However, I'm not sure about the following:
> - Why do I need to give the `-L/usr/lib/ghc-6.12.3/' option? (It seems
> like ghc ought to know about that, implicitly.)
> - Why do I need to explicitly link against the 3 standard C libraries:
> `m', `ffi', and `rt'? (I've never needed to do this, previously, when
> I was building/testing this project statically.)
>
The first is because GHC doesn't link its libraries using -L and basenames,
but full path names. Since you used a basename, you also have to use -L to
tell it how to expand the basename.
The second is because those libraries are needed by libHSrts, and since you
linked that explicitly you need to link its dependencies explicitly as well.
--
brandon s allbery allbery.b at gmail.com
wandering unix systems administrator (available) (412) 475-9364 vm/sms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20110911/cd620e5f/attachment.htm>
More information about the Glasgow-haskell-users
mailing list