Hans Wennborg via llvm-dev
2015-Aug-24 23:40 UTC
[llvm-dev] [3.7 Release] RC3 has been tagged, let's wrap this up
It seems this is a cmake vs autoconf thing. With cmake, it builds correctly, but with autoconf I get the same error as you. I probably shouldn't have made this change while we were in the release process as it was potentially risky :-/ I've reverted it now, so hopefully the next build should be problem free. Thanks, Hans On Fri, Aug 21, 2015 at 5:09 AM, Dimitry Andric <dimitry at andric.com> wrote:> Strangely, the clang-tools-extra stuff does build if I manually check it out like so (without any symlinks): > > . <-- https://llvm.org/svn/llvm-project/llvm/branches/release_37 > tools/clang <-- https://llvm.org/svn/llvm-project/cfe/branches/release_37 > tools/clang/tools/extra <-- https://llvm.org/svn/llvm-project/clang-tools-extra/branches/release_37 > > I'll investigate, because it would be nice to have those tools. > > -Dimitry > >> On 21 Aug 2015, at 13:42, Nikola Smiljanic <popizdeh at gmail.com> wrote: >> >> Hi Dmitry, if I understood Hans clang-extra wasn't part of the build prior to rc3. Just delete it and run script with --no-checkout. >> >> On Fri, Aug 21, 2015 at 7:15 PM, Dimitry Andric <dimitry at andric.com> wrote: >> Hm, it does not seem to compile at all here? The build ends with: >> >> In file included from /home/dim/llvm-3.7.0/rc3/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/ApplyReplacements.cpp:17: >> /home/dim/llvm-3.7.0/rc3/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../include/clang-apply-replacements/Tooling/ApplyReplacements.h:19:10: fatal error: 'clang/Tooling/Refactoring.h' file not found >> #include "clang/Tooling/Refactoring.h" >> ^ >> 1 error generated. >> >> Any idea? I had no problems at all with -rc2. >> >> -Dimitry >> >> > On 21 Aug 2015, at 02:51, Hans Wennborg <hans at chromium.org> wrote: >> > >> > Hello everyone, >> > >> > 3.7-rc3 has just been tagged. Testers, please test, build binaries, >> > upload to the sftp and report results to this thread. >> > >> > Again, a lot of patches got merged between rc2 and rc3, but hopefully >> > nothing that should upset things. >> > >> > One thing that did change is that the release script now correctly >> > symlinks clang-tools-extra into the build. If this causes problems on >> > your platform, please just remove it. >> > >> > This is a release candidate in the real sense: at this point I have >> > zero release blockers on my radar. I will now only accept fixes for >> > critical regressions, and if nothing comes up, rc3 will be promoted to >> > 3.7.0-final. >> > >> > Documentation and release note patches are still welcome all the way >> > up until the final tag goes in. >> > >> > Issues that were on my radar, but I don't consider blocking: >> > >> > - Sanitizer test failures on various platforms, e.g. PR24222. We never >> > ran these tests in previous releases, so it's not a regression. It >> > would be great if the sanitizer folks could look into the test >> > failures, but it's not blocking 3.7. >> > >> > - PR24273: "[ARM] Libc++abi built in-tree with libunwind fails in >> > __cxa_allocate_exception", Renato will exclude libc++ from his build >> > for now. >> > >> > - Lack of key functions in some Instruction classes causing build >> > failures without -fno-rtti >> > (http://lists.llvm.org/pipermail/llvm-dev/2015-August/089010.html). No >> > patches have been forthcoming, so this will not get fixed for 3.7. At >> > least we correctly report -fno-rtti in llvm-config built with CMake >> > now. >> > >> > - r244221: "[SPARC] Don't compare arch name as a string, use the enum >> > instead", owner is unresponsive. >> > >> > - "[lldb] r245020 - [MIPS]Handle floating point and aggregate return >> > types in SysV-mips [32 bit] ABI", owner is unresponsive. >> > >> > >> > Cheers, >> > Hans >> >> >
Dimitry Andric via llvm-dev
2015-Aug-25 21:44 UTC
[llvm-dev] [3.7 Release] RC3 has been tagged, let's wrap this up
Hans, Note that the patches I posted solved the problems, at least for me. :) -Dimitry> On 25 Aug 2015, at 01:40, Hans Wennborg <hans at chromium.org> wrote: > > It seems this is a cmake vs autoconf thing. With cmake, it builds > correctly, but with autoconf I get the same error as you. > > I probably shouldn't have made this change while we were in the > release process as it was potentially risky :-/ I've reverted it now, > so hopefully the next build should be problem free. > > Thanks, > Hans > > On Fri, Aug 21, 2015 at 5:09 AM, Dimitry Andric <dimitry at andric.com> wrote: >> Strangely, the clang-tools-extra stuff does build if I manually check it out like so (without any symlinks): >> >> . <-- https://llvm.org/svn/llvm-project/llvm/branches/release_37 >> tools/clang <-- https://llvm.org/svn/llvm-project/cfe/branches/release_37 >> tools/clang/tools/extra <-- https://llvm.org/svn/llvm-project/clang-tools-extra/branches/release_37 >> >> I'll investigate, because it would be nice to have those tools. >> >> -Dimitry >> >>> On 21 Aug 2015, at 13:42, Nikola Smiljanic <popizdeh at gmail.com> wrote: >>> >>> Hi Dmitry, if I understood Hans clang-extra wasn't part of the build prior to rc3. Just delete it and run script with --no-checkout. >>> >>> On Fri, Aug 21, 2015 at 7:15 PM, Dimitry Andric <dimitry at andric.com> wrote: >>> Hm, it does not seem to compile at all here? The build ends with: >>> >>> In file included from /home/dim/llvm-3.7.0/rc3/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/ApplyReplacements.cpp:17: >>> /home/dim/llvm-3.7.0/rc3/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../include/clang-apply-replacements/Tooling/ApplyReplacements.h:19:10: fatal error: 'clang/Tooling/Refactoring.h' file not found >>> #include "clang/Tooling/Refactoring.h" >>> ^ >>> 1 error generated. >>> >>> Any idea? I had no problems at all with -rc2. >>> >>> -Dimitry >>> >>>> On 21 Aug 2015, at 02:51, Hans Wennborg <hans at chromium.org> wrote: >>>> >>>> Hello everyone, >>>> >>>> 3.7-rc3 has just been tagged. Testers, please test, build binaries, >>>> upload to the sftp and report results to this thread. >>>> >>>> Again, a lot of patches got merged between rc2 and rc3, but hopefully >>>> nothing that should upset things. >>>> >>>> One thing that did change is that the release script now correctly >>>> symlinks clang-tools-extra into the build. If this causes problems on >>>> your platform, please just remove it. >>>> >>>> This is a release candidate in the real sense: at this point I have >>>> zero release blockers on my radar. I will now only accept fixes for >>>> critical regressions, and if nothing comes up, rc3 will be promoted to >>>> 3.7.0-final. >>>> >>>> Documentation and release note patches are still welcome all the way >>>> up until the final tag goes in. >>>> >>>> Issues that were on my radar, but I don't consider blocking: >>>> >>>> - Sanitizer test failures on various platforms, e.g. PR24222. We never >>>> ran these tests in previous releases, so it's not a regression. It >>>> would be great if the sanitizer folks could look into the test >>>> failures, but it's not blocking 3.7. >>>> >>>> - PR24273: "[ARM] Libc++abi built in-tree with libunwind fails in >>>> __cxa_allocate_exception", Renato will exclude libc++ from his build >>>> for now. >>>> >>>> - Lack of key functions in some Instruction classes causing build >>>> failures without -fno-rtti >>>> (http://lists.llvm.org/pipermail/llvm-dev/2015-August/089010.html). No >>>> patches have been forthcoming, so this will not get fixed for 3.7. At >>>> least we correctly report -fno-rtti in llvm-config built with CMake >>>> now. >>>> >>>> - r244221: "[SPARC] Don't compare arch name as a string, use the enum >>>> instead", owner is unresponsive. >>>> >>>> - "[lldb] r245020 - [MIPS]Handle floating point and aggregate return >>>> types in SysV-mips [32 bit] ABI", owner is unresponsive. >>>> >>>> >>>> Cheers, >>>> Hans >>> >>> >>-------------- 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/20150825/350c3868/attachment-0001.sig>
Hans Wennborg via llvm-dev
2015-Aug-25 22:54 UTC
[llvm-dev] [3.7 Release] RC3 has been tagged, let's wrap this up
Thanks, we should probably do something like that after this release, but for now I think it's best to revert to safety. On Tue, Aug 25, 2015 at 2:44 PM, Dimitry Andric <dimitry at andric.com> wrote:> Hans, > > Note that the patches I posted solved the problems, at least for me. :) > > -Dimitry > >> On 25 Aug 2015, at 01:40, Hans Wennborg <hans at chromium.org> wrote: >> >> It seems this is a cmake vs autoconf thing. With cmake, it builds >> correctly, but with autoconf I get the same error as you. >> >> I probably shouldn't have made this change while we were in the >> release process as it was potentially risky :-/ I've reverted it now, >> so hopefully the next build should be problem free. >> >> Thanks, >> Hans >> >> On Fri, Aug 21, 2015 at 5:09 AM, Dimitry Andric <dimitry at andric.com> wrote: >>> Strangely, the clang-tools-extra stuff does build if I manually check it out like so (without any symlinks): >>> >>> . <-- https://llvm.org/svn/llvm-project/llvm/branches/release_37 >>> tools/clang <-- https://llvm.org/svn/llvm-project/cfe/branches/release_37 >>> tools/clang/tools/extra <-- https://llvm.org/svn/llvm-project/clang-tools-extra/branches/release_37 >>> >>> I'll investigate, because it would be nice to have those tools. >>> >>> -Dimitry >>> >>>> On 21 Aug 2015, at 13:42, Nikola Smiljanic <popizdeh at gmail.com> wrote: >>>> >>>> Hi Dmitry, if I understood Hans clang-extra wasn't part of the build prior to rc3. Just delete it and run script with --no-checkout. >>>> >>>> On Fri, Aug 21, 2015 at 7:15 PM, Dimitry Andric <dimitry at andric.com> wrote: >>>> Hm, it does not seem to compile at all here? The build ends with: >>>> >>>> In file included from /home/dim/llvm-3.7.0/rc3/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/ApplyReplacements.cpp:17: >>>> /home/dim/llvm-3.7.0/rc3/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../include/clang-apply-replacements/Tooling/ApplyReplacements.h:19:10: fatal error: 'clang/Tooling/Refactoring.h' file not found >>>> #include "clang/Tooling/Refactoring.h" >>>> ^ >>>> 1 error generated. >>>> >>>> Any idea? I had no problems at all with -rc2. >>>> >>>> -Dimitry >>>> >>>>> On 21 Aug 2015, at 02:51, Hans Wennborg <hans at chromium.org> wrote: >>>>> >>>>> Hello everyone, >>>>> >>>>> 3.7-rc3 has just been tagged. Testers, please test, build binaries, >>>>> upload to the sftp and report results to this thread. >>>>> >>>>> Again, a lot of patches got merged between rc2 and rc3, but hopefully >>>>> nothing that should upset things. >>>>> >>>>> One thing that did change is that the release script now correctly >>>>> symlinks clang-tools-extra into the build. If this causes problems on >>>>> your platform, please just remove it. >>>>> >>>>> This is a release candidate in the real sense: at this point I have >>>>> zero release blockers on my radar. I will now only accept fixes for >>>>> critical regressions, and if nothing comes up, rc3 will be promoted to >>>>> 3.7.0-final. >>>>> >>>>> Documentation and release note patches are still welcome all the way >>>>> up until the final tag goes in. >>>>> >>>>> Issues that were on my radar, but I don't consider blocking: >>>>> >>>>> - Sanitizer test failures on various platforms, e.g. PR24222. We never >>>>> ran these tests in previous releases, so it's not a regression. It >>>>> would be great if the sanitizer folks could look into the test >>>>> failures, but it's not blocking 3.7. >>>>> >>>>> - PR24273: "[ARM] Libc++abi built in-tree with libunwind fails in >>>>> __cxa_allocate_exception", Renato will exclude libc++ from his build >>>>> for now. >>>>> >>>>> - Lack of key functions in some Instruction classes causing build >>>>> failures without -fno-rtti >>>>> (http://lists.llvm.org/pipermail/llvm-dev/2015-August/089010.html). No >>>>> patches have been forthcoming, so this will not get fixed for 3.7. At >>>>> least we correctly report -fno-rtti in llvm-config built with CMake >>>>> now. >>>>> >>>>> - r244221: "[SPARC] Don't compare arch name as a string, use the enum >>>>> instead", owner is unresponsive. >>>>> >>>>> - "[lldb] r245020 - [MIPS]Handle floating point and aggregate return >>>>> types in SysV-mips [32 bit] ABI", owner is unresponsive. >>>>> >>>>> >>>>> Cheers, >>>>> Hans >>>> >>>> >>> >