Date: Wed, 21 Mar 2001 20:24:51 +0200 (WET) From: Andris Pavenis To: Tim Van Holder Cc: Eli Zaretskii , 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 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