From: pavenis AT lanet DOT lv Message-ID: To: Eli Zaretskii Date: Mon, 24 May 1999 14:21:21 +0300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: gcc 3.0 CC: djgpp-workers AT delorie DOT com, sparhawk AT eunet DOT at References: In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.11) Reply-To: djgpp-workers AT delorie DOT com No such problem with DJGPP port of egcs-1.1.2. FIL d:/ap/devel/eph/src/../../../lib/include/a1_util.h d:/ap/devel/eph/src 0 FIL d:/ap/devel/eph/src/../../../lib/include/__a1_cfg.h d:/ap/devel/eph/src 0 FIL c:/djgpp/include/stdio.h d:/ap/devel/eph/src 0 FIL c:/djgpp/include/sys/version.h d:/ap/devel/eph/src 0 FIL c:/djgpp/include/sys/djtypes.h d:/ap/devel/eph/src 0 Anyway there is one LFN related problem with -fxref as filename used for cross-reference listing is invalid without LFN support Andris On 23 May 99, at 14:14, Eli Zaretskii wrote: > Is this problem solved in the latest ports of EGCS? If not, perhaps > somebody could look into it? > > ------- Start of forwarded message ------- > From: sparhawk AT eunet DOT at (Gerhard Gruber) > Newsgroups: comp.os.msdos.djgpp > Subject: -fxref bug? > Date: Wed, 12 Aug 1998 21:27:36 GMT > Organization: EUnet Austria > X-Trace: fleetstreet.Austria.EU.net 902957322 17899 193.154.184.162 (12 Aug 1998 21:28:42 GMT) > X-Complaints-To: abuse AT Austria DOT EU DOT net > NNTP-Posting-Date: 12 Aug 1998 21:28:42 GMT > X-Newsreader: Forte Agent 1.5/32.451 > To: djgpp AT delorie DOT com > DJ-Gateway: from newsgroup comp.os.msdos.djgpp > X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id RAB00964 > X-Mailing-List: djgpp AT delorie DOT com > X-Unsubscribes-To: listserv AT delorie DOT com > Precedence: bulk > Content-Type: text/plain; charset=us-ascii > Content-Length: 1248 > X-Status: > > I'm currently writing a classbrowser and for this I need the information > produced by the -fxref switch. Now I noticed a rather weird statement and I > wonder if this is intentional or if it is a bug. > > This is a sample compiled on a hpux system with gcc: > > FIL /sfa/entw/src/gui2/gru/tracer/test.cpp /sfa/entw/src/gui2/gru/tracer 0 > FIL /usr/local/lib/gcc-lib/hppa1.0-hp-hpux10.20/2.7.2.1/include/stdio.h > /sfa/entw/src/gui2/gru/tracer 0 > > 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 > > I don't know if you know what the fields mean from that output (I'd be > grateful for any information because I don't know what the numbers mean). The > first entry is the fully qualified sourcefilename and the second parameter is > the working directory where the compiler is called from, to compile the > source. In the second line the first entry gives the pathname of an include > file. 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? > > - -- > Bye, > Gerhard > > email: sparhawk AT eunet DOT at > g DOT gruber AT sis DOT co DOT at > > Spelling corrections are appreciated. > ------- End of forwarded message ------- >