Date:	Wed, 21 Mar 2001 20:24:51 +0200 (WET)
From:	Andris Pavenis <pavenis AT lanet DOT lv>
To:	Tim Van Holder <tim DOT van DOT holder AT pandora DOT be>
Cc:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, djgpp-workers AT delorie DOT com
Subject:	RE: About release of gcc-2.95.3 for DJGPP
In-Reply-To:	<CAEGKOHJKAAFPKOCLHDIOEMKCBAA.tim.van.holder@pandora.be>
Message-ID:	<Pine.A41.4.05.10103212005120.135218-100000@ieva06.lanet.lv>
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 Wed, 21 Mar 2001, Tim Van Holder wrote:

> > > But there we can be much more certain it's a file we can safely
> > > overwrite.
> >
> > I don't see how: the fact that gcov usurped file names which end with
> > `.gcov' doesn't mean no one else in the world uses that extension.
> True, but since gcov appends ".gcov" to the source file name (as provided
> by the .bb files, I expect), it will create foo.gcov.gcov in the case
> someone should use foo.gcov as a source file name. This leaves only the
> case where there is a non-gcov foo.c.gcov present. The chances of that
> happening are a LOT smaller than hitting an existing file when trying to
> work 'gco' into the extension in an 8+3 environment.
> 
> > I think it is quite deterministic.  In fact, I think it is easier to
> > explain to the users what names they should expect than to write the
> > code which implements that ;-)
> Hehe - true, I suppose. But given that Joe Six-Pack seems to write
> 'gcc foo.o -o foo.c' often, it's safe to assume many more people will
> accidentally kill files with gcov (then again, I don't know if many people
> will actually use gcov).
> 
> > > If no other tools depend on the .gcov extension, I suppose it would be
> > > cleaner for gcov to require a '-o output' on SFN DOS, leaving the choice
> > > of an acceptable file name to the user.
> >
> > This might break automated scripts.
> gcov is young enough to make this unlikely, though.
> Then again, emacs' make-docfile requires a '-o' on DOS, and that breaks the
> standard makefile too :-P (yeah, I know I'm supposed to use config.bat)
> 
> Look, anything is fine by me - I run in an LFN environment anyway; I was
> just trying to point out some problems.
> 

Command line option -o have different meaning for gcov as far as I
understood from gcc info files:

 
`-o'
     The directory where the object files live.  Gcov will search for
     `.bb', `.bbg', and `.da' files in this directory.

Anyway I think it's impossible to prevent all possibilities to
do bad things. So we should stop at some reasonable place.

So let's see how it will look in real life as archives are already
uploaded to ftp.delorie.com


Perhaps we'll see other questions more often:

	as using binutils earlier than 2.95 will most likely no more 
	supported with port of gcc-3.0, I made -mbnu210 the default
	and added emitting warning when -mno-bnu210 is used to remind 
	to upgrade binutils. 

Unfortunatelly as we know from earlier experience, many users don't read 
readme files, so perhaps somebody will simply try to use binaries of
gcc-2.95.3 together with old binutils and run into trouble. It's mentioned
in gnu/gcc-2.953/problems.txt but the question is, how many users will see
it. But I don't see any other reasonable way how to force users to upgrade
binutils (we cannot provide compatibility with old binutils forever ...) 

Andris

- Raw text -