[LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I begins

[Dimitry Andric]

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>