On 19 October 2016 at 18:35, Matt Turner <matts...@gmail.com> wrote: > On Wed, Oct 19, 2016 at 9:54 AM, Marek Olšák <mar...@gmail.com> wrote: >> On Wed, Oct 19, 2016 at 6:06 PM, Emil Velikov <emil.l.veli...@gmail.com> >> wrote: >>> On 19 October 2016 at 15:55, Marek Olšák <mar...@gmail.com> wrote: >>>> On Wed, Oct 19, 2016 at 12:47 PM, Emil Velikov <emil.l.veli...@gmail.com> >>>> wrote: >>>>> On 19 October 2016 at 11:35, Grigori Goronzy <g...@chown.ath.cx> wrote: >>>>>> On 2016-10-04 12:32, Emil Velikov wrote: >>>>>>> >>>>>>> On 2 October 2016 at 14:17, Axel Davy <axel.d...@ens.fr> 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++. A LLVM build is still churning, but I believe you're spot on.
Thanks Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
