[haskell-llvm] unknown symbol `DW.ref.__gxx_personality_v0'

[Carter Schonwald]

Indeed.

Frankly I think any work on ghci support should be deferred until after the
ghc 7.8 release because all ghci ffi interaction problems will be gone due
to the switch to ghci using the dylib version of object files. (Rather than
the current ghci only linker that pretends static objects are dylibs).

 In fact if you try out using ghci in the current ghc head, you should be
able to use the llvm bindings without any changes, none. Yes none.

I am against any messing with llvm c++ build process approaches, especially
since llvm has an open plugin architecture that needs dylibs.

Likewise on the c++ ffi front, I will be the mentor of a Haskell gsoc
student project that hopes to simplify the Haskell c++ ffi story or at
least take a serious crack at it.  This might be handy for future
augmentation of our llvm bindings In a tractable way. (Or so it's hoped)

Basically a lot of the suggested issues in current llvmhs look like they
will be solved at the ecosystem level in the next 3-6 months and do not
require effort or increased complexity on the llvm HS side.


Point being: if you want to use llvm HS from ghci, use current ghc head. If
that doesn't work, that is a bug that needs to be fixed, and likely a bug
on the ghc hq side.  (And better to have such things caught before the
7.8.1 release. ). Note that I recommend building ghc head with the native
code backend unless you have llvm version >= 3.3 be the only llvm build
visible in your path.

Cheers

-carter


On Sunday, May 19, 2013, Nathan Howell wrote:

> GHCi's loader has a lot of quirks. C++ for the most part doesn't load
> reliably... I've long since given up using llvm (or any C++ object files)
> from GHCi and Template Haskell. Here's a related ticket:
> http://hackage.haskell.org/trac/ghc/ticket/3333.
>
> -n
>
>
> On Sun, May 19, 2013 at 9:34 AM, Henning Thielemann <
> lemming at henning-thielemann.de <javascript:_e({}, 'cvml',
> 'lemming at henning-thielemann.de');>> wrote:
>
>>
>> On Sun, 19 May 2013, Henning Thielemann wrote:
>>
>>  I am trying to get llvm-base running with pkg-config. I already got
>>> HelloJIT running both with static and dynamic linking. However when running
>>> ghci, I get:
>>>
>>> examples> ghci-7.6.3 -Wall -package=llvm-tf-3.0.0.0.2
>>> -package=llvm-base-3.0.0.2 HelloJIT.hs
>>> GHCi, version 7.6.3: http://www.haskell.org/ghc/  :? for help
>>> ...
>>> Loading package llvm-base-3.0.0.2 ... linking ... ghc:
>>> /cabal/lib/llvm-base-3.0.0.2/**ghc-7.6.3/HSllvm-base-3.0.0.2.**o:
>>> unknown symbol `DW.ref.__gxx_personality_v0'
>>> ghc: unable to load package `llvm-base-3.0.0.2'
>>>
>>>
>>> I suspect that it has to do with the call to LLVMInitializeNativeTarget
>>> in extra.cpp. I have read that gxx_personality is for exception handling
>>> and can be found in stdc++. I added 'extra-libraries: stdc++' to
>>> llvm-base.cabal, but this does not help.
>>>
>>> Any idea how to solve that problem?
>>>
>>
>> six hours later ...
>>
>> I found the problem: It was the -fPIC option suggested by llvm-config:
>>
>> $ llvm-config --cflags
>> -I/usr/lib/llvm-3.0/include -DNDEBUG -D_GNU_SOURCE
>> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -g
>> -O2 -fomit-frame-pointer -fPIC
>>
>> Without the -fPIC option everything works. However, now I don't know what
>> to actually write into the Cflags of llvm.pc.
>>
>>
>> ______________________________**_________________
>> Haskell-llvm mailing list
>> Haskell-llvm at projects.haskell.**org <javascript:_e({}, 'cvml',
>> 'Haskell-llvm at projects.haskell.org');>
>> http://projects.haskell.org/**cgi-bin/mailman/listinfo/**haskell-llvm<http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-llvm>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://projects.haskell.org/pipermail/haskell-llvm/attachments/20130519/719d20a0/attachment-0001.htm>