On Mon, Jul 20, 2015 at 2:37 PM, Dimitry Andric <dimi...@andric.com> wrote: > On 20 Jul 2015, at 22:50, Hans Wennborg <h...@chromium.org> wrote: >> >> On Sat, Jul 18, 2015 at 3:17 PM, Dimitry Andric <dimi...@andric.com> wrote: >>> On 17 Jul 2015, at 01:09, Hans Wennborg <h...@chromium.org> wrote: >>>> >>>> On Thu, Jul 16, 2015 at 3:47 PM, Dimitry Andric <dimi...@andric.com> wrote: >>>>> On 17 Jul 2015, at 00:31, Hans Wennborg <h...@chromium.org> wrote: >>>>>> >>>>>> Dear testers, >>>>>> >>>>>> 3.7.0-rc1 was just tagged; please start your testing engines :-) >>>>>> >>>>>> Upload binaries to the sftp and report your results to this thread. >>>>>> >>>>>> I'm sorry for the delay between branching and tagging. The changes to >>>>>> the release script took a little longer than I hoped. >>>>>> >>>>>> Thanks for helping with the release, and do let me know of any issues, >>>>>> questions, etc. >>>>>> >>>>>> The tracking bug for release blockers is PR24126. >>>>> >>>>> Is it OK to do an autoconf build? The CMake build tries to build various >>>>> components which do not yet work on FreeBSD, e.g. libcxxabi does not >>>>> compile at all, libcompiler-rt has a bunch of test failures, etc. >>>>> Alternatively, can I disable these components in the CMake build locally? >>>> >>>> Yes, go ahead and use the autoconf build. >>>> >>>> Can you send a patch to test-release.sh that makes this default for >>>> FreeBSD? It's already the default for Darwin. >>> >>> Here it is. While here, I replaced the multiple calls to uname -s with a >>> variable assignment. >>> >>> It's currently building for FreeBSD 10.x i386 and amd64. >> >> Renato ran into the same problem of some components not working when >> building on ARM and has a patch out for disabling them: >> http://reviews.llvm.org/D11326 >> >> That might be a better approach actually. Since we didn't use to >> include libcxx or libcxxabi in previous releases, feel free to disable >> those (but please file bugs for the problems anyway). For compiler-rt, >> we did include that in previous releases so it would be good if we >> could make it work. What errors are you running into? > > The compilation fails because it cannot find unwind.h, since we still > have not cleaned up our act in FreeBSD, and chose one of the 4 (or so) > available versions we have in our tree, to install into the standard > system include directories. > > Other than that, I recall there were still several test failures in the > sanitizer parts. This needs more work to get it completely done. > > I'm not sure if the llvm libunwind you added in r242543 will get picked > up during the build of compiler-rt, but that could at least provide > *some* form of unwinding library. It would be better for FreeBSD to > just import that wholesale, so we can finally ditch libgcc... :-)
If r242543 fixes it, that's great. Otherwise, feel free to exclude compiler-rt or fall back to autoconf (doesn't that need unwind.h too, though?) - whatever is most appropriate for FreeBSD. Thanks, Hans _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
