Indeed! First bug fix listed here: https://ccache.dev/releasenotes.html#_ccache_3_7_7
Thanks all and sorry for the noise! On Mon, 20 Jan 2020 at 21:33, Balay, Satish <ba...@mcs.anl.gov> wrote: > And looks like the issue is fixed in ccache 3.7.7 > > Satish > > ------- > > balay@sb /home/balay/petsc (master=) > $ which gcc > /usr/lib64/ccache/gcc > balay@sb /home/balay/petsc (master=) > $ ccache --version > ccache version 3.7.7 > > Copyright (C) 2002-2007 Andrew Tridgell > Copyright (C) 2009-2020 Joel Rosdahl > > This program is free software; you can redistribute it and/or modify it > under > the terms of the GNU General Public License as published by the Free > Software > Foundation; either version 3 of the License, or (at your option) any later > version. > balay@sb /home/balay/petsc (master=) > $ make clean > /usr/bin/rm -f -r ./arch-linux-c-debug/tests > ./arch-linux-c-debug/tests/testfiles > /usr/bin/rm -f -r arch-linux-c-debug/obj arch-linux-c-debug/lib/libpetsc* > /home/balay/petsc/arch-linux-c-debug/include/petsc*.mod > arch-linux-c-debug/lib/petsc/conf/files > balay@sb /home/balay/petsc (master=) > $ make -f gmakefile arch-linux-c-debug/obj/sys/objects/init.o > /usr/bin/python ./config/gmakegen.py --petsc-arch=arch-linux-c-debug > /usr/bin/python /home/balay/petsc/config/gmakegentest.py > --petsc-dir=/home/balay/petsc --petsc-arch=arch-linux-c-debug > --testdir=./arch-linux-c-debug/tests > Use "/usr/bin/gmake V=1" to see verbose compile lines, "/usr/bin/gmake > V=0" to suppress. > CC arch-linux-c-debug/obj/sys/objects/init.o > balay@sb /home/balay/petsc (master=) > $ head -n 3 arch-linux-c-debug/obj/sys/objects/init.d > arch-linux-c-debug/obj/sys/objects/init.o: \ > /home/balay/petsc/src/sys/objects/init.c \ > /home/balay/petsc/include/petscsys.h \ > balay@sb /home/balay/petsc (master=) > $ make -f gmakefile arch-linux-c-debug/obj/sys/objects/init.o > make: 'arch-linux-c-debug/obj/sys/objects/init.o' is up to date. > balay@sb /home/balay/petsc (master=) > $ touch /home/balay/petsc/include/petscsys.h > balay@sb /home/balay/petsc (master=) > $ make -f gmakefile arch-linux-c-debug/obj/sys/objects/init.o > Use "/usr/bin/gmake V=1" to see verbose compile lines, "/usr/bin/gmake > V=0" to suppress. > CC arch-linux-c-debug/obj/sys/objects/init.o > balay@sb /home/balay/petsc (master=) > $ > > > > On Mon, 20 Jan 2020, Balay, Satish via petsc-dev wrote: > > > Downgrading to ccache-3.4.3-2.fc30.x86_64.rpm [on F31] changes this > behavior for me. > > > > Satish > > > > ----- > > > > wget > https://kojipkgs.fedoraproject.org//packages/ccache/3.4.3/2.fc30/x86_64/ccache-3.4.3-2.fc30.x86_64.rpm > > rpm -Uvh --oldpackage ccache-3.4.3-2.fc30.x86_64.rpm > > > > ------ > > > > $ head -n 3 arch-linux-c-debug/obj/sys/objects/init.d > > arch-linux-c-debug/obj/sys/objects/init.o: \ > > /home/balay/petsc/src/sys/objects/init.c \ > > /home/balay/petsc/include/petscsys.h \ > > > > > > > > > > On Mon, 20 Jan 2020, Lisandro Dalcin wrote: > > > > > Ups! Not a GCC issue, but still relevant to all us... > > > > > > The issue happens only if using ccache. I have the system ccache > package > > > installed, and ccache is used via symlinks. > > > > > > $ mpicc -show > > > gcc -I/usr/include/mpich-x86_64 -L/usr/lib64/mpich/lib -Wl,-rpath > > > -Wl,/usr/lib64/mpich/lib -Wl,--enable-new-dtags -lmpi > > > $ which gcc > > > /usr/lib64/ccache/gcc > > > > > > Rebuilding this way: > > > > > > $ make clean > > > ... > > > $ MPICH_CC=/usr/bin/gcc make > > > ... > > > $ head -n 3 arch-linux2-c-debug/obj/sys/objects/init.d > > > arch-linux2-c-debug/obj/sys/objects/init.o: \ > > > /home/devel/petsc/dev/src/sys/objects/init.c \ > > > /home/devel/petsc/dev/include/petscsys.h \ > > > > > > so I'm back to normal. > > > > > > Now I need to figure out if this is a ccache miss-configuration (maybe > from > > > legacy values in my $HOME config file) or something else. > > > > > > > > > On Mon, 20 Jan 2020 at 18:42, <j...@jedbrown.org> wrote: > > > > > > > Ah, you're right. I'm still suspicious about how this behavior > appeared on > > > > your machine. Would be interesting to check a vanilla build or gcc-10 > > > > branch. I'm still learning toward it being unintentional. > > > > > > > > On Jan 20, 2020 07:57, Lisandro Dalcin <dalc...@gmail.com> wrote: > > > > > > > > > > > > > > > > On Mon, 20 Jan 2020 at 17:07, Jed Brown <j...@jedbrown.org> wrote: > > > > > > > > From my man page (contradicting the behavior Lisandro observed): > > > > > > > > -MD -MD is equivalent to -M -MF file, except that -E is not > implied. > > > > The driver > > > > determines file based on whether an -o option is given. If > it is, > > > > the driver uses > > > > its argument but with a suffix of .d, otherwise it takes the > name > > > > of the input > > > > file, removes any directory components and suffix, and > applies a .d > > > > suffix. > > > > > > > > > > > > Lisandro, what does your man page say? > > > > > > > > > > > > It says exactly the same. But you are confusing the flag, -MF is > about > > > > naming the output dep filename, i.e. > ompi-optg/obj/sys/objects/init.d in > > > > your example, that is just fine, I do get that file with that name. > > > > My issue is with the contents GCC writes within that dep file, > > > > specifically the TARGET, which can be specified with -MT, but it is > > > > cumbersome to do, unless you use "-MT $@", though no idea how to > update > > > > configure for that. > > > > > > > > > > > > -- > > > > Lisandro Dalcin > > > > ============ > > > > Research Scientist > > > > Extreme Computing Research Center (ECRC) > > > > King Abdullah University of Science and Technology (KAUST) > > > > http://ecrc.kaust.edu.sa/ > > > > > > > > > > > > > > > > > > > > > > -- Lisandro Dalcin ============ Research Scientist Extreme Computing Research Center (ECRC) King Abdullah University of Science and Technology (KAUST) http://ecrc.kaust.edu.sa/