On Wed, Oct 19, 2016 at 9:54 AM, Marek Olšák <[email protected]> wrote: > On Wed, Oct 19, 2016 at 6:06 PM, Emil Velikov <[email protected]> > wrote: >> On 19 October 2016 at 15:55, Marek Olšák <[email protected]> wrote: >>> On Wed, Oct 19, 2016 at 12:47 PM, Emil Velikov <[email protected]> >>> wrote: >>>> On 19 October 2016 at 11:35, Grigori Goronzy <[email protected]> wrote: >>>>> On 2016-10-04 12:32, Emil Velikov wrote: >>>>>> >>>>>> On 2 October 2016 at 14:17, Axel Davy <[email protected]> wrote: >>>>>>> >>>>>>> I'd prefer myself Oct 14, because we have a lot of patches for nine, and >>>>>>> they deserve more cleaning and testing, but if it's Oct 7, we'll try be >>>>>>> on >>>>>>> time. >>>>>>> >>>>>> 14th it is. As mentioned before: _don't_ wait for the last week to get >>>>>> things merged. Once you're reasonably happy just send the new work >>>>>> review and commit it. >>>>>> Same applies for bugfixes :-) >>>>>> >>>>> >>>>> What happened to these plans? It is the October 19th already. Nine fixes >>>>> have trickled into Mesa and radv was merged also. What's the holdup? >>>>> >>>> I've spent a (bit too many) days on trying to get things working with LLVM >>>> 3.9. >>>> So on my end, I'll consider it broken and let the LLVM wizards take care >>>> of it. >>> >>> Is the LLVM 3.9 issue related to radeonsi? >>> >> Plain gallium, as per below. >> >> ../../../../src/gallium/auxiliary/.libs/libgallium.a(lp_bld_misc.o): >> In function >> `llvm::RTDyldMemoryManager::getSymbolAddress(std::__cxx11::basic_string<char, >> std::char_tra >> its<char>, std::allocator<char> > const&)': >> /usr/local/include/llvm/ExecutionEngine/RTDyldMemoryManager.h:87: >> undefined reference to >> `llvm::RTDyldMemoryManager::getSymbolAddressInProcess(std::__cxx11::basic_string<ch >> ar, std::char_traits<char>, std::allocator<char> > const&)' >> /usr/local/include/llvm/ExecutionEngine/RTDyldMemoryManager.h:87: >> undefined reference to >> `llvm::RTDyldMemoryManager::getSymbolAddressInProcess(std::__cxx11::basic_string<ch >> ar, std::char_traits<char>, std::allocator<char> > const&)' >> >> An identical symbol with different signature is provided by the static >> lib and header: >> >> $ objdump -CtT libLLVMRuntimeDyld.a | grep >> "llvm::RTDyldMemoryManager::getSymbolAddressInProcess" >> ... 0000000000000149 >> llvm::RTDyldMemoryManager::getSymbolAddressInProcess(std::string >> const&) >> >> $ grep getSymbolAddressInProcess .../include/ >> RTDyldMemoryManager.h: static uint64_t >> getSymbolAddressInProcess(const std::string &Name); >> >> And in the LLVM 3.8 case (which works like a charm): >> >> $ objdump -CtT libLLVMRuntimeDyld.a | grep >> "llvm::RTDyldMemoryManager::getSymbolAddressInProcess" >> ...0000000000000181 >> llvm::RTDyldMemoryManager::getSymbolAddressInProcess(std::__cxx11::basic_string<char, >> std::char_traits<char>, std::allocator<char> > const&) >> >> $ grep getSymbolAddressInProcess .../include/ >> RTDyldMemoryManager.h: static uint64_t >> getSymbolAddressInProcess(const std::string &Name); >> >> It smells like partial/incomplete build with the C++11 ABI, but trying >> to untangle the lot is quite time consuming. > > I admit I have no idea what all that means.
This looks like C++ ABI mismatch. See https://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/ for details. Recompile LLVM and Mesa with the same g++. _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
