Message-ID:	<B0000039144@stargate.astr.lu.lv>
From:	"Andris Pavenis" <pavenis AT lanet DOT lv>
To:	Gerhard Gruber <sparhawk AT eunet DOT at>, Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Date:	Thu, 13 Aug 1998 12:07:17 +0300
MIME-Version:	1.0
Subject:	Re: -fxref bug?
CC:	djgpp AT delorie DOT com
References:	<35d9002c DOT 1456253 AT news DOT Austria DOT EU DOT net>
In-reply-to:	<Pine.SUN.3.91.980813104505.2812G-100000@is>

Date sent:      	Thu, 13 Aug 1998 10:45:23 +0300 (IDT)
From:           	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Subject:        	Re: -fxref bug?

> 
> On Wed, 12 Aug 1998, Gerhard Gruber wrote:
> 
> > And this is a sample compiled with DJGPP on DOS/W95:
> > FIL d:/bc/srcparse/test.cpp d:/bc 0
> > FIL d:/bc/d:/gnu/include/stdio.h d:/bc 0
> > 
> > As you can see, in DJGPP the compilepath is appended before the include
> > filepaths whereas this is not the case on UNIX systems. Now I wonder if this
> > is intentional (why?) or if this is a bug?

Simply one (or more) place where we should look for DOS style file 
paths (that are different from Unix ones) is missed. So it should be 
considered as a bug. At least I was not able to find it in sources of 
egcs-2.91.53 quickly (I think there should be no problems to patch 
sources of gcc-2.8.1 if I'll know where is the problem)

> 
> Seems like a bug to me, especially since the path name in second line
> is obviously garbled.
> 
> Many Unix-born programs assume that any file name which doesn't begin
> with a slash is a relative file name.  Seems like this is another case
> of such lossage.  (When porting a package, I usually grep the entire
> source tree for strings like '/' and "/", just to hunt down all these
> cases.)
> 
> Would you please consider locating this bug in the GCC sources and
> posting a patch?  Thanks in advance.
> 

- Raw text -