[cfe-dev] [3.7 Release] RC1 has been tagged, Testing Phase I begins

[Hans Wennborg]

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