[llvm-dev] [lldb-dev] [3.7 Release] RC3 has been tagged, let's wrap this up
Dimitry Andric via llvm-dev
llvm-dev at lists.llvm.org
Sun Aug 23 03:15:32 PDT 2015
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-dev at 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 <dimitry at 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-dev at 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-dev at 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 at 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 <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
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> lldb-dev mailing list
>>>>> lldb-dev at lists.llvm.org
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- 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/20150823/df154943/attachment.sig>
More information about the llvm-dev
mailing list