llvm dev - May 2012 - [LLVMdev] lli unable to resolve symbol _ZNKSt3__16locale9use_facetERNS0_2idE in bitcode

Resending :(. Any pointers?

tia

On 5/21/2012 2:46 PM, Ashok Nalkund wrote:
> On 5/21/2012 11:15 AM, Nick Lewycky wrote:
>> Ashok Nalkund wrote:
>>> Resending, any pointers? I demangled the symbol and it turns out to
be:
>>> std::__1::locale::use_facet(std::__1::locale::id&) const
>>
>> My guess is that you've got a .bc file produced on a mac using
libc++
>> (hence the ::_1 part) and you're trying to run it on linux with
>> libstdc++ (which doesn't use inline namespaces, the
'::_1::' part). That
>> won't work.
>>
>> Nick
>
> Thanks for the clue. I had earlier tried to use libc++ and there were
> some remnants of that try. I've now cleaned up and now it gets past the
> use_facet error.
>
> It now complains about '__dso_handle'. I saw a bug already reported
but
> its status is still NEW:
> http://llvm.org/bugs/show_bug.cgi?id=7847
>
> As mentioned in the bug, the problem seems to be when the interpreter is
> used.
>
> There is another post on cfe-dev list:
>
http://clang-developers.42468.n3.nabble.com/Configuring-HAVE-DSO-HANDLE-by-CMake-td3423707.html
>
> Any thoughts?
>
> thanks
> ashok
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

> Resending :(. Any pointers?
Are you seeing missing __dso_handle with the interpreter or with the JIT?

Ciao, Duncan.
>
> tia
>
> On 5/21/2012 2:46 PM, Ashok Nalkund wrote:
>> On 5/21/2012 11:15 AM, Nick Lewycky wrote:
>>> Ashok Nalkund wrote:
>>>> Resending, any pointers? I demangled the symbol and it turns
out to be:
>>>> std::__1::locale::use_facet(std::__1::locale::id&) const
>>>
>>> My guess is that you've got a .bc file produced on a mac using
libc++
>>> (hence the ::_1 part) and you're trying to run it on linux with
>>> libstdc++ (which doesn't use inline namespaces, the
'::_1::' part). That
>>> won't work.
>>>
>>> Nick
>>
>> Thanks for the clue. I had earlier tried to use libc++ and there were
>> some remnants of that try. I've now cleaned up and now it gets past
the
>> use_facet error.
>>
>> It now complains about '__dso_handle'. I saw a bug already
reported but
>> its status is still NEW:
>> http://llvm.org/bugs/show_bug.cgi?id=7847
>>
>> As mentioned in the bug, the problem seems to be when the interpreter
is
>> used.
>>
>> There is another post on cfe-dev list:
>>
http://clang-developers.42468.n3.nabble.com/Configuring-HAVE-DSO-HANDLE-by-CMake-td3423707.html
>>
>> Any thoughts?
>>
>> thanks
>> ashok
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

With MCJIT.

On 5/22/2012 12:54 PM, Duncan Sands wrote:
>> Resending :(. Any pointers?
>
> Are you seeing missing __dso_handle with the interpreter or with the JIT?
>
> Ciao, Duncan.
>
>>
>> tia
>>
>> On 5/21/2012 2:46 PM, Ashok Nalkund wrote:
>>> On 5/21/2012 11:15 AM, Nick Lewycky wrote:
>>>> Ashok Nalkund wrote:
>>>>> Resending, any pointers? I demangled the symbol and it
turns out to be:
>>>>> std::__1::locale::use_facet(std::__1::locale::id&)
const
>>>>
>>>> My guess is that you've got a .bc file produced on a mac
using libc++
>>>> (hence the ::_1 part) and you're trying to run it on linux
with
>>>> libstdc++ (which doesn't use inline namespaces, the
'::_1::' part). That
>>>> won't work.
>>>>
>>>> Nick
>>>
>>> Thanks for the clue. I had earlier tried to use libc++ and there
were
>>> some remnants of that try. I've now cleaned up and now it gets
past the
>>> use_facet error.
>>>
>>> It now complains about '__dso_handle'. I saw a bug already
reported but
>>> its status is still NEW:
>>> http://llvm.org/bugs/show_bug.cgi?id=7847
>>>
>>> As mentioned in the bug, the problem seems to be when the
interpreter is
>>> used.
>>>
>>> There is another post on cfe-dev list:
>>>
http://clang-developers.42468.n3.nabble.com/Configuring-HAVE-DSO-HANDLE-by-CMake-td3423707.html
>>>
>>> Any thoughts?
>>>
>>> thanks
>>> ashok
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Ashok Nalkund wrote:
>
> Resending :(. Any pointers?
Fundamentally the issue is that the system linker is supposed to define 
__dso_handle when linking, but since there is no system linker between 
your build of the .bc files and running lli, nobody has defined it.

It seems reasonable to me that lli should define __dso_handle if it's 
declared in the module.

You could module tools/lli/lli.cpp to add a global:

   char *dummy_dso_handle = 0;

and tie it to __dso_handle via.

   if (GlobalVariable *DSO =
Mod->getGlobalVariable("__dso_handle"))
     if (!DSO->hasInitializer())
       EE->updateGlobalMapping(DSO, &dummy_dso_handle);

somewhere in main(), say after disabling lazy compilation. Entirely 
untested though; we might need to give dummy_dso_handle a real value.

Nick
> tia
>
> On 5/21/2012 2:46 PM, Ashok Nalkund wrote:
>> On 5/21/2012 11:15 AM, Nick Lewycky wrote:
>>> Ashok Nalkund wrote:
>>>> Resending, any pointers? I demangled the symbol and it turns
out to be:
>>>> std::__1::locale::use_facet(std::__1::locale::id&) const
>>>
>>> My guess is that you've got a .bc file produced on a mac using
libc++
>>> (hence the ::_1 part) and you're trying to run it on linux with
>>> libstdc++ (which doesn't use inline namespaces, the
'::_1::' part). That
>>> won't work.
>>>
>>> Nick
>>
>> Thanks for the clue. I had earlier tried to use libc++ and there were
>> some remnants of that try. I've now cleaned up and now it gets past
the
>> use_facet error.
>>
>> It now complains about '__dso_handle'. I saw a bug already
reported but
>> its status is still NEW:
>> http://llvm.org/bugs/show_bug.cgi?id=7847
>>
>> As mentioned in the bug, the problem seems to be when the interpreter
is
>> used.
>>
>> There is another post on cfe-dev list:
>>
http://clang-developers.42468.n3.nabble.com/Configuring-HAVE-DSO-HANDLE-by-CMake-td3423707.html
>>
>>
>> Any thoughts?
>>
>> thanks
>> ashok
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

Nick Lewycky wrote:
> Ashok Nalkund wrote:
>>
>> Resending :(. Any pointers?
>
> Fundamentally the issue is that the system linker is supposed to define
> __dso_handle when linking, but since there is no system linker between
> your build of the .bc files and running lli, nobody has defined it.
>
> It seems reasonable to me that lli should define __dso_handle if it's
> declared in the module.
>
> You could module tools/lli/lli.cpp to add a global:
>
>     char *dummy_dso_handle = 0;
>
> and tie it to __dso_handle via.
>
>     if (GlobalVariable *DSO =
Mod->getGlobalVariable("__dso_handle"))
>       if (!DSO->hasInitializer())
Obvious error here, that should read:

       if (DSO->isDeclaration())

to test whether it's a declaration. Still untested of course. :)
>         EE->updateGlobalMapping(DSO,&dummy_dso_handle);
>
> somewhere in main(), say after disabling lazy compilation. Entirely
> untested though; we might need to give dummy_dso_handle a real value.
>
> Nick
>
>> tia
>>
>> On 5/21/2012 2:46 PM, Ashok Nalkund wrote:
>>> On 5/21/2012 11:15 AM, Nick Lewycky wrote:
>>>> Ashok Nalkund wrote:
>>>>> Resending, any pointers? I demangled the symbol and it
turns out to be:
>>>>> std::__1::locale::use_facet(std::__1::locale::id&)
const
>>>>
>>>> My guess is that you've got a .bc file produced on a mac
using libc++
>>>> (hence the ::_1 part) and you're trying to run it on linux
with
>>>> libstdc++ (which doesn't use inline namespaces, the
'::_1::' part). That
>>>> won't work.
>>>>
>>>> Nick
>>>
>>> Thanks for the clue. I had earlier tried to use libc++ and there
were
>>> some remnants of that try. I've now cleaned up and now it gets
past the
>>> use_facet error.
>>>
>>> It now complains about '__dso_handle'. I saw a bug already
reported but
>>> its status is still NEW:
>>> http://llvm.org/bugs/show_bug.cgi?id=7847
>>>
>>> As mentioned in the bug, the problem seems to be when the
interpreter is
>>> used.
>>>
>>> There is another post on cfe-dev list:
>>>
http://clang-developers.42468.n3.nabble.com/Configuring-HAVE-DSO-HANDLE-by-CMake-td3423707.html
>>>
>>>
>>> Any thoughts?
>>>
>>> thanks
>>> ashok
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

Hi Nick,
> Fundamentally the issue is that the system linker is supposed to define
> __dso_handle when linking, but since there is no system linker between
> your build of the .bc files and running lli, nobody has defined it.
>
> It seems reasonable to me that lli should define __dso_handle if it's
> declared in the module.
>
> You could module tools/lli/lli.cpp to add a global:
>
>     char *dummy_dso_handle = 0;
>
> and tie it to __dso_handle via.
>
>     if (GlobalVariable *DSO =
Mod->getGlobalVariable("__dso_handle"))
>       if (!DSO->hasInitializer())
>         EE->updateGlobalMapping(DSO,&dummy_dso_handle);
>
> somewhere in main(), say after disabling lazy compilation. Entirely
> untested though; we might need to give dummy_dso_handle a real value.
this is already done in JIT.cpp, search for HAVE___DSO_HANDLE.  Probably
the interpreter and MCJIT just need to get the same logic.

Ciao, Duncan.
>
> Nick
>
>> tia
>>
>> On 5/21/2012 2:46 PM, Ashok Nalkund wrote:
>>> On 5/21/2012 11:15 AM, Nick Lewycky wrote:
>>>> Ashok Nalkund wrote:
>>>>> Resending, any pointers? I demangled the symbol and it
turns out to be:
>>>>> std::__1::locale::use_facet(std::__1::locale::id&)
const
>>>>
>>>> My guess is that you've got a .bc file produced on a mac
using libc++
>>>> (hence the ::_1 part) and you're trying to run it on linux
with
>>>> libstdc++ (which doesn't use inline namespaces, the
'::_1::' part). That
>>>> won't work.
>>>>
>>>> Nick
>>>
>>> Thanks for the clue. I had earlier tried to use libc++ and there
were
>>> some remnants of that try. I've now cleaned up and now it gets
past the
>>> use_facet error.
>>>
>>> It now complains about '__dso_handle'. I saw a bug already
reported but
>>> its status is still NEW:
>>> http://llvm.org/bugs/show_bug.cgi?id=7847
>>>
>>> As mentioned in the bug, the problem seems to be when the
interpreter is
>>> used.
>>>
>>> There is another post on cfe-dev list:
>>>
http://clang-developers.42468.n3.nabble.com/Configuring-HAVE-DSO-HANDLE-by-CMake-td3423707.html
>>>
>>>
>>> Any thoughts?
>>>
>>> thanks
>>> ashok
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev