Hans Wennborg
2015-Jul-20 20:50 UTC
[LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I begins
On Sat, Jul 18, 2015 at 3:17 PM, Dimitry Andric <dimitry at andric.com> wrote:> On 17 Jul 2015, at 01:09, Hans Wennborg <hans at chromium.org> wrote: >> >> On Thu, Jul 16, 2015 at 3:47 PM, Dimitry Andric <dimitry at andric.com> wrote: >>> On 17 Jul 2015, at 00:31, Hans Wennborg <hans at 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? Thanks, Hans
Dimitry Andric
2015-Jul-20 21:37 UTC
[LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I begins
On 20 Jul 2015, at 22:50, Hans Wennborg <hans at chromium.org> wrote:> > On Sat, Jul 18, 2015 at 3:17 PM, Dimitry Andric <dimitry at andric.com> wrote: >> On 17 Jul 2015, at 01:09, Hans Wennborg <hans at chromium.org> wrote: >>> >>> On Thu, Jul 16, 2015 at 3:47 PM, Dimitry Andric <dimitry at andric.com> wrote: >>>> On 17 Jul 2015, at 00:31, Hans Wennborg <hans at 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... :-) -Dimitry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150720/e2ad1ee9/attachment.sig>
Hans Wennborg
2015-Jul-20 21:55 UTC
[LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I begins
On Mon, Jul 20, 2015 at 2:37 PM, Dimitry Andric <dimitry at andric.com> wrote:> On 20 Jul 2015, at 22:50, Hans Wennborg <hans at chromium.org> wrote: >> >> On Sat, Jul 18, 2015 at 3:17 PM, Dimitry Andric <dimitry at andric.com> wrote: >>> On 17 Jul 2015, at 01:09, Hans Wennborg <hans at chromium.org> wrote: >>>> >>>> On Thu, Jul 16, 2015 at 3:47 PM, Dimitry Andric <dimitry at andric.com> wrote: >>>>> On 17 Jul 2015, at 00:31, Hans Wennborg <hans at 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