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 <broeker AT physik DOT rwth-aachen DOT de>
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:	<Pine.SUN.3.91.1010319135514.23067G-100000@is>
Message-ID:	<Pine.LNX.4.10.10103251457170.15102-100000@acp3bf>
MIME-Version:	1.0
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

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.

- Raw text -