Finally, all building and testing succeeded, even with clang-tools-extra now (the tarballs became ~15% bigger). :)
Uploaded: SHA256 (clang+llvm-3.7.0-rc3-i386-unknown-freebsd10.tar.xz) = 319a7d6758bad7976dab2774309504432a69705c5662b38e05062018b71f655f SHA256 (clang+llvm-3.7.0-rc3-amd64-unknown-freebsd10.tar.xz) = 91997accc86379f7b2334ca9444a1fe017210871774153b87f4b1723125807fc -Dimitry > On 23 Aug 2015, at 01:33, Dimitry Andric via llvm-dev > <llvm-...@lists.llvm.org> wrote: > > Right, I found out the problem. It's because clang-tools-extra's test > Makefile uses the temporary filename "lit.tmp" for both its main > lit.site.cfg, and for Unit/lit.site.cfg. If these make jobs get run > simultaneously, one or the other temp file can unexpectedly disappear. > > The following fixes it, similar to what is done in clang's own test Makefile. > Hans, are you OK with me checking this in to clang-tools-extra trunk (not > sure who owns that), then merging it to the release_37 branch? Then it is at > least fixed for the final build. > > Index: tools/clang/tools/extra/test/Makefile > =================================================================== > --- tools/clang/tools/extra/test/Makefile (revision 245796) > +++ tools/clang/tools/extra/test/Makefile (working copy) > @@ -60,12 +60,12 @@ > Unit/lit.site.cfg: FORCE > @echo "Making Unit/lit.site.cfg for Clang extra tools..." > @$(MKDIR) $(dir $@) > - @$(ECHOPATH) s=@LLVM_LIBS_DIR@=$(LibDir)=g >> lit.tmp > - @$(ECHOPATH) s=@CLANG_TOOLS_BINARY_DIR@=$(PROJ_OBJ_DIR)/..=g >> > lit.tmp > - @$(ECHOPATH) s=@TARGET_TRIPLE@=$(TARGET_TRIPLE)=g >> lit.tmp > - @$(ECHOPATH) s=@CLANG_TOOLS_SOURCE_DIR@=$(PROJ_SRC_DIR)/..=g >> > lit.tmp > - @sed -f lit.tmp $(PROJ_SRC_DIR)/Unit/lit.site.cfg.in > $@ > - @-rm -f lit.tmp > + @$(ECHOPATH) s=@LLVM_LIBS_DIR@=$(LibDir)=g >> unit.tmp > + @$(ECHOPATH) s=@CLANG_TOOLS_BINARY_DIR@=$(PROJ_OBJ_DIR)/..=g >> > unit.tmp > + @$(ECHOPATH) s=@TARGET_TRIPLE@=$(TARGET_TRIPLE)=g >> unit.tmp > + @$(ECHOPATH) s=@CLANG_TOOLS_SOURCE_DIR@=$(PROJ_SRC_DIR)/..=g >> > unit.tmp > + @sed -f unit.tmp $(PROJ_SRC_DIR)/Unit/lit.site.cfg.in > $@ > + @-rm -f unit.tmp > > clean:: > @ find . -name Output | xargs rm -fr > > -Dimitry > >> On 23 Aug 2015, at 01:13, Dimitry Andric <dimi...@andric.com> wrote: >> >> Still no complete go, doing the tests on i386 failed with some weird sed >> error: >> >> [...] >> Making Unit/lit.site.cfg for Clang extra tools... >> sed: lit.tmp: No such file or directory >> Makefile:61: recipe for target 'Unit/lit.site.cfg' failed >> gmake[2]: *** [Unit/lit.site.cfg] Error 1 >> >> Strangely enough, this does not happen on amd64. Maybe it is some sort of >> race condition? Did anybody see this too? >> >> Back to the investigation again... :( >> >> -Dimitry >> >>> On 22 Aug 2015, at 21:23, Dimitry Andric via llvm-dev >>> <llvm-...@lists.llvm.org> wrote: >>> >>> It's building with this patch now, already at Phase3, so it seems to work: >>> >>> Index: trunk/utils/release/test-release.sh >>> =================================================================== >>> --- trunk/utils/release/test-release.sh (revision 245679) >>> +++ trunk/utils/release/test-release.sh (working copy) >>> @@ -266,43 +268,36 @@ >>> check_valid_urls >>> >>> for proj in $projects ; do >>> - if [ -d $proj.src ]; then >>> - echo "# Reusing $proj $Release-$RC sources" >>> + case $proj in >>> + llvm|openmp) >>> + projsrc=$proj.src >>> + ;; >>> + cfe) >>> + projsrc=llvm.src/tools/clang >>> + ;; >>> + clang-tools-extra) >>> + projsrc=llvm.src/tools/clang/tools/extra >>> + ;; >>> + compiler-rt|libcxx|libcxxabi|libunwind|test-suite) >>> + projsrc=llvm.src/projects/$proj >>> + ;; >>> + *) >>> + echo "error: unknown project $proj" >>> + exit 1 >>> + ;; >>> + esac >>> + >>> + if [ -d $projsrc ]; then >>> + echo "# Reusing $proj $Release-$RC sources in $projsrc" >>> continue >>> fi >>> - echo "# Exporting $proj $Release-$RC sources" >>> - if ! svn export -q $Base_url/$proj/$ExportBranch $proj.src ; then >>> + echo "# Exporting $proj $Release-$RC sources to $projsrc" >>> + if ! svn export -q $Base_url/$proj/$ExportBranch $projsrc ; then >>> echo "error: failed to export $proj project" >>> exit 1 >>> fi >>> done >>> >>> - echo "# Creating symlinks" >>> - cd $BuildDir/llvm.src/tools >>> - if [ ! -h clang ]; then >>> - ln -s ../../cfe.src clang >>> - fi >>> - cd $BuildDir/cfe.src/tools >>> - if [ ! -h extra ]; then >>> - ln -s ../../clang-tools-extra.src extra >>> - fi >>> - cd $BuildDir/llvm.src/projects >>> - if [ -d $BuildDir/test-suite.src ] && [ ! -h test-suite ]; then >>> - ln -s ../../test-suite.src test-suite >>> - fi >>> - if [ -d $BuildDir/compiler-rt.src ] && [ ! -h compiler-rt ]; then >>> - ln -s ../../compiler-rt.src compiler-rt >>> - fi >>> - if [ -d $BuildDir/libcxx.src ] && [ ! -h libcxx ]; then >>> - ln -s ../../libcxx.src libcxx >>> - fi >>> - if [ -d $BuildDir/libcxxabi.src ] && [ ! -h libcxxabi ]; then >>> - ln -s ../../libcxxabi.src libcxxabi >>> - fi >>> - if [ -d $BuildDir/libunwind.src ] && [ ! -h libunwind ]; then >>> - ln -s ../../libunwind.src libunwind >>> - fi >>> - >>> cd $BuildDir >>> } >>> >>> -Dimitry >>> >>>> On 22 Aug 2015, at 18:54, Dimitry Andric via llvm-dev >>>> <llvm-...@lists.llvm.org> wrote: >>>> >>>> The problem seems to be caused by the way the symlinks are setup in >>>> test-release.sh, e.g. like so: >>>> >>>> llvm.src/tools/clang -> ../../cfe.src >>>> cfe.src/tools/extra -> ../../clang-tools-extra.src >>>> >>>> When it then tries to access the path >>>> llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../../../include, >>>> it fails. I tried this on both FreeBSD, OSX and Linux, but it fails >>>> everywhere. >>>> >>>> For example, on Linux: >>>> >>>> $ ls -l ~/foo/llvm.src/tools/clang >>>> lrwxrwxrwx 1 dim dim 13 2015-08-22 18:40:16 >>>> /home/dim/foo/llvm.src/tools/clang -> ../../cfe.src/ >>>> $ ls -l ~/foo/cfe.src/tools/extra >>>> lrwxrwxrwx 1 dim dim 27 2015-08-22 18:53:04 >>>> /home/dim/foo/cfe.src/tools/extra -> ../../clang-tools-extra.src/ >>>> $ ls -l >>>> ~/foo/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling >>>> total 16 >>>> -rw-r--r-- 1 dim dim 8983 2015-08-22 18:17:18 ApplyReplacements.cpp >>>> -rw-r--r-- 1 dim dim 526 2015-08-22 18:17:18 Makefile >>>> $ ls -l >>>> ~/foo/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../../../include >>>> ls: cannot access >>>> /home/dim/foo/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../../../include: >>>> No such file or directory >>>> >>>> Note that >>>> llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../.. >>>> goes back to the top level, where *.src is checked out: >>>> >>>> $ ls -l >>>> ~/foo/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../.. >>>> total 12 >>>> drwxr-xr-x 16 dim dim 4096 2015-08-22 18:17:16 cfe.src/ >>>> drwxr-xr-x 14 dim dim 4096 2015-08-22 18:40:32 clang-tools-extra.src/ >>>> drwxr-xr-x 16 dim dim 4096 2015-08-22 18:13:58 llvm.src/ >>>> >>>> Of course at a level even below that, there is little chance of an include >>>> directory existing. How does anybody else manage to build using the >>>> test-release.sh script, and having clang-tools-extra? >>>> >>>> -Dimitry >>>> >>>>> On 21 Aug 2015, at 14:09, Dimitry Andric via lldb-dev >>>>> <lldb-dev@lists.llvm.org> 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 <popiz...@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 <dimi...@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 <h...@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 >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> lldb-dev mailing list >>>>> lldb-dev@lists.llvm.org >>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>>> >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> llvm-...@lists.llvm.org >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-...@lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > > _______________________________________________ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
