Mail Archives: djgpp/1998/08/13/06:21:52
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?
>
> 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.
>
Here is patch for cp/xref.c that gives partial fix to this problem
(output filename is still not in DOS 8+3 format). I tested patch with
egcs-2.91.53, but it should be Ok for gcc-2.8.1 with some offset
however I didn't rebuild gcc-2.8.1. I don't know when (or if) I'll
uploaded fixed binaries.
Andris
------------------------------------------------------------------------------------------
*** xref.c~ Sun Jul 12 08:20:20 1998
--- xref.c Thu Aug 13 12:57:36 1998
***************
*** 36,41 ****
--- 36,48 ----
#define FILE_NAME_JOINER "/"
#endif
+ #ifdef __DJGPP__
+ #define FILE_NAME_ABSOLUTE_P(NAME) \
+ ((NAME[0] == '/') || \
+ (isascii(NAME[0]) && NAME[1]==':' && \
+ (NAME[2]=='/' || NAME[2]=='\\')))
+ #endif
+
/* Nonzero if NAME as a file name is absolute. */
#ifndef FILE_NAME_ABSOLUTE_P
#define FILE_NAME_ABSOLUTE_P(NAME) (NAME[0] == '/')
- Raw text -