On Fri, Dec 23, 2016 at 5:20 PM, Teresa Johnson <tejohnson at google.com> wrote:> I'm really not sure, and I don't build or use libc++ myself. I was hoping > someone else would answer this part, so maybe fork it into a different thread > about that specifically so that the question gets more visibility.Will do if I don't forget about it. In the meantime, given no explanation for cmake warning about code that builds and works fine if done manually with the toolchain to be used, I'll try to build with the updates config and see how far it gets, since gold is not used now. I want to say I doubt it will work, but I'll be optimistic. Expect a build report sometime today or tomorrow......
On Sat, Dec 24, 2016 at 6:20 AM, Carsten Mattner <carstenmattner at gmail.com> wrote:> On Fri, Dec 23, 2016 at 5:20 PM, Teresa Johnson <tejohnson at google.com> > wrote: > > > I'm really not sure, and I don't build or use libc++ myself. I was hoping > > someone else would answer this part, so maybe fork it into a different > thread > > about that specifically so that the question gets more visibility. > > Will do if I don't forget about it. > > In the meantime, given no explanation for cmake warning about code that > builds and works fine if done manually with the toolchain to be used,I assume you mean the libstdc++ issue - I wonder if cmake is actually picking up a different libstdc++ than expected. Can you look at the output under the produced CMakeFiles directory? Specifically, I would imagine there will be a more detailed error for this test in the CMakeError.log file, and there should be some output in CMakeOutput.log (in the latter search for LLVM_NO_OLD_LIBSTDCXX). What does the error output look like specifically? There may be debugging options to cmake to help figure out what is going on, not completely sure though. I'll try to build with the updates config and see how far it gets, since> gold is not > used now. I want to say I doubt it will work, but I'll be optimistic. > Expect a build report sometime today or tomorrow...... >Ok sure. FYI I'm off for a few days now and later next week so my response times are slow right now. Teresa -- Teresa Johnson | Software Engineer | tejohnson at google.com | 408-460-2413 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161224/4528761d/attachment.html>
So, archlinux doesn't seem to package lld. Since the binaries from llvm.org don't work here, maybe I can find another way to avoid running two llvm builds (one to build lld, one to thinlto-lld rebuild). TBD.
After figuring out the fault in the configuration step and rebuilding,
and then rebuilding again by forcing it with `ninja -k 16`, I managed to
build everything but 12 ninja targets.
I have to sift through them before I can report more, and I don't
don't know if it's small enough to post here, but some of the more
interesting errors are:
llvm/projects/compiler-rt/lib/tsan/dd/dd_interceptors.cc:226:20:
error: redefinition of 'realpath'
INTERCEPTOR(char*, realpath, const char *path, char *resolved_path) {
^
/usr/include/bits/stdlib.h:37:8: note: previous definition is here
__NTH (realpath (const char *__restrict __name, char *__restrict __resolved))
[...]
libomp.so
duplicate symbol __kmp_get_reduce_method in version script
duplicate symbol __kmp_itt_fini_ittlib in version script
duplicate symbol __kmp_itt_init_ittlib in version script
LLVM ERROR: A @@ version cannot be undefined