X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs Date: Sun, 25 Mar 2001 15:02:34 +0200 (MET DST) From: Hans-Bernhard Broeker X-Sender: broeker AT acp3bf To: djgpp-workers AT delorie DOT com Subject: Re: About release of gcc-2.95.3 for DJGPP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Mon, 19 Mar 2001, Eli Zaretskii wrote: > > On Mon, 19 Mar 2001 pavenis AT lanet DOT lv wrote: > > > gcov generates name of output file by appending to name ".gcov". > > So for foo.c we're getting foo.c.gcov. > > Making foo.gcov would probably solve this. Not really. For code coming from header files (extern inline functions, C++ inline methods), gcov wants to create foo.h.gcov, which would collide with foo.c.gcov. In 'gcov -l' mode, it's even worse: you'll get filenames like 'bar.c.foo.h.gcov' for inlines from foo.h contained in bar.c Last time we discussed this (the 'gcc 3.0' thread in djgpp-workers, around April 2000), the only possible solution we came up with was to set up a directory tree, i.e.: gcov/foo.c gcov/foo.h gcov/foo.c_/bar.h (the last one my on-the-spot invention of today). OTOH, it's not strictly necessary for gcov itself to work in SFN, as long as an LFN environment is available at all: the data files carry short names (foo.bb, foo.da, foo.bbg), and it should suffice to run gcov in the LFN environment, later, in case the target program itself doesn't work in LFN. -- Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.