Dimitry Andric via llvm-dev
2015-Aug-22 23:13 UTC
[llvm-dev] [lldb-dev] [3.7 Release] RC3 has been tagged, let's wrap this up
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-------------- 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/b803fc94/attachment.sig>
Dimitry Andric via llvm-dev
2015-Aug-22 23:33 UTC
[llvm-dev] [lldb-dev] [3.7 Release] RC3 has been tagged, let's wrap this up
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
>
-------------- 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/626b794e/attachment.sig>
Dimitry Andric via llvm-dev
2015-Aug-23 10:15 UTC
[llvm-dev] [lldb-dev] [3.7 Release] RC3 has been tagged, let's wrap this up
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>