Okay, I'm stuck again. Let's back up and see what's happening: ~/src$ git clone llvm/ ~/src$ mkdir llvm-build/ ~/src/llvm-build$ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug ../llvm ~/src/llvm-build$ ninja
Now, ~/src/llvm-build/lib/libLLVMCore.a contains DWARF information that points to files ~/src/llvm/include/llvm/ADT/ilist.h, ~/src/llvm/lib/IR/Core.cpp etc. ~/src/llvm-build$ ninja install The *.a files are copied to /usr/local/lib, but the *.h files are also copied to /usr/local/include/llvm. The DWARF information is not rewritten as part of the "install". ~/src/fooapp$ clang++ -g -I/usr/local/include -L/usr/local/lib ... The fooapp binary is going to contain DWARF information pointing to /usr/local/include/llvm/ADT/ilist.h (because I did -I) _and_ ~/src/llvm/include/llvm/ADT/ilist.h (because of libLLVMCore.a). lldb crashes. gdb hums along just fine in the face of this conflict (the codebase is enormous; sorry, I couldn't find out how exactly). Now, I cannot "fix" my build by -I'ing ~/src/llvm/include because some essential headers are build artifacts. The only thing I can do is to try and put a plist into the dSYM (which doesn't seem to work either, or I'm doing something wrong). In the general case, there's nothing special about my build: this problem needs to be solved in lldb for the general audience. Please advise. Thanks. Ram On Fri, Oct 23, 2015 at 1:00 PM, Greg Clayton <gclay...@apple.com> wrote: > I guess LLDB was just helping your resolve build issues and make your product > better... :-) > > Let us know how things go once you get your build fixed. > > Greg > >> On Oct 23, 2015, at 9:45 AM, Ramkumar Ramachandra <artag...@gmail.com> wrote: >> >> Hi, >> >> On Wed, Oct 21, 2015 at 2:27 PM, Greg Clayton <gclay...@apple.com> wrote: >>> .... >> >> Atleast, can we have lldb report a nicer error? >> >> There is conflicting DWARF information for type ilist...: >> /sandbox/rramacha/3p/derived/List.h >> /sandbox/rramacha/3p/install/List.h >> >> /sandbox/rramacha/idivide/bin/libmwcgir_vm.so is to blame. >> >> This is likely a problem with your build scripts. In any case, the >> compiler is responsible for this mess. >> >>> It sounds like you fixed your symlink issue. So a few questions: >>> 1 - do you have just one type now in your libmwcgir_vm_rt.dylib.dSYM when >>> you type: >>> >>> (lldb) image lookup -t "iplist<llvm::Function, >>> llvm::ilist_traits<llvm::Function> >" >>> >>> If so, then you will need to find other competing definitions in other >>> shared libraries and see if any of them differ by comparing the full >>> "clang_type" value. >> >> Yeah, after resolving the symlink, I realized that there are two >> different paths. I'm attempting to fix my build system. > _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
