| Message ID | Pine.LNX.4.64.1205251620480.25409@wotan.suse.de |
|---|---|
| State | New |
| Headers | show |
Hello Michael, On May 25, 2012, at 16:30 , Michael Matz wrote: > I've noticed that libitm is always rebuild with a non-bootstrap tree even > with merely a sequence of two makes. The reason turns out to be that > installation of unwind.h from libgcc, which is always done with a simple > make: This should have been fixed by rev 187839 after the thread initiated at http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01596.html Could you please tell if that works for you ? Thanks in advance, Olivier
Hi, On Fri, 25 May 2012, Olivier Hainque wrote: > > I've noticed that libitm is always rebuild with a non-bootstrap tree even > > with merely a sequence of two makes. The reason turns out to be that > > installation of unwind.h from libgcc, which is always done with a simple > > make: > > This should have been fixed by rev 187839 after the thread > initiated at > > http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01596.html > > Could you please tell if that works for you ? Super, yes, that works. Though I still wonder if the whole copy-over-to-gcc business shouldn't be dependend on anything newly built. I can't see the use in copying over the same unchanged files to a place where they already are. And generally installing with -p also can't hurt, can it? Ciao, Michael.
On May 25, 2012, at 17:17 , Michael Matz wrote: >> This should have been fixed by rev 187839 ... > Super, yes, that works. Great :) > Though I still wonder if the whole copy-over-to-gcc business shouldn't be > dependend on anything newly built. I can't see the use in copying > over the same unchanged files to a place where they already are. > And generally installing with -p also can't hurt, can it? I suppose not but don't know the full story here.
Index: configure.ac =================================================================== --- configure.ac (revision 187708) +++ configure.ac (working copy) @@ -93,8 +93,8 @@ srcpwd=`cd ${srcdir} ; ${PWDCMD-pwd}` # We pass INSTALL explicitly to sub-makes. Make sure that it is not # a relative path. -if test "$INSTALL" = "${srcdir}/install-sh -c"; then - INSTALL="${srcpwd}/install-sh -c" +if test "$INSTALL" = "${srcdir}/install-sh -c -p"; then + INSTALL="${srcpwd}/install-sh -c -p" fi # Set srcdir to "." if that's what it is. Index: config/proginstall.m4 =================================================================== --- config/proginstall.m4 (revision 187708) +++ config/proginstall.m4 (working copy) @@ -54,12 +54,12 @@ case $as_dir/ in echo one > conftest.one echo two > conftest.two mkdir conftest.dir - if "$as_dir/$ac_prog$ac_exec_ext" -c conftest.one conftest.two "`pwd`/conftest.dir" && + if "$as_dir/$ac_prog$ac_exec_ext" -c -p conftest.one conftest.two "`pwd`/conftest.dir" && test -s conftest.one && test -s conftest.two && test -s conftest.dir/conftest.one && test -s conftest.dir/conftest.two then - ac_cv_path_install="$as_dir/$ac_prog$ac_exec_ext -c" + ac_cv_path_install="$as_dir/$ac_prog$ac_exec_ext -c -p" break 3 fi fi
Hi, I've noticed that libitm is always rebuild with a non-bootstrap tree even with merely a sequence of two makes. The reason turns out to be that installation of unwind.h from libgcc, which is always done with a simple make: # make # make -d ... dest=../.././gcc/include/tmp$$-unwind.h; \ cp unwind.h $dest; \ chmod a+r $dest; \ sh ../../../gcc/libgcc/../move-if-change $dest ../.././gcc/include/unwind.h (this is still fine, because it uses move-if-change) ... make install-leaf DESTDIR=../.././gcc \ slibdir= libsubdir= MULTIOSDIR=. ... /bin/sh ../../../gcc/libgcc/../mkinstalldirs ../.././gcc/include /usr/bin/install -c -m 644 unwind.h ../.././gcc/include This one updates the mtime of gcc/include/unwind.h, and is the problematic one, ultimately resulting in: Prerequisite `/matz/gcc/svn/real-trunk/dev/gcc/include/unwind.h' is newer than target `aatree.lo'. And all of libitm (our only c++ library) is rebuilt as all objects therein have a dependency on unwind.h. There are multiple variants to fix: a) use install -p (or -C) generally for all INSTALLs in all makefiles b) use a) for only libgcc Makefile c) don't repeatedly install the same files on a remake even though nothing was compiled newly (perhaps some stamp files could be used to make leaf-install a no-op if nothing new was built?) I've checked that hardcoding -p for INSTALL in the top-level Makefile solves this problem (see patch), but perhaps you prefer one of the others (or can think of something else entirely). Ciao, Michael.