Ashok Nalkund
2012-May-22 16:48 UTC
[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
Duncan Sands
2012-May-22 19:54 UTC
[LLVMdev] lli unable to resolve symbol _ZNKSt3__16locale9use_facetERNS0_2idE in bitcode
> 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
Ashok Nalkund
2012-May-22 20:00 UTC
[LLVMdev] lli unable to resolve symbol _ZNKSt3__16locale9use_facetERNS0_2idE in bitcode
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
Nick Lewycky
2012-May-23 04:34 UTC
[LLVMdev] lli unable to resolve symbol _ZNKSt3__16locale9use_facetERNS0_2idE in bitcode
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
2012-May-23 04:53 UTC
[LLVMdev] lli unable to resolve symbol _ZNKSt3__16locale9use_facetERNS0_2idE in bitcode
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 >
Duncan Sands
2012-May-23 07:13 UTC
[LLVMdev] lli unable to resolve symbol _ZNKSt3__16locale9use_facetERNS0_2idE in bitcode
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
Possibly Parallel Threads
- [LLVMdev] lli unable to resolve symbol _ZNKSt3__16locale9use_facetERNS0_2idE in bitcode
- [LLVMdev] lli unable to resolve symbol _ZNKSt3__16locale9use_facetERNS0_2idE in bitcode
- [LLVMdev] lli unable to resolve symbol _ZNKSt3__16locale9use_facetERNS0_2idE in bitcode
- [LLVMdev] lli unable to resolve symbol _ZNKSt3__16locale9use_facetERNS0_2idE in bitcode
- [LLVMdev] lli unable to resolve symbol _ZNKSt3__16locale9use_facetERNS0_2idE in bitcode