This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Fixinc and mvme328.h (2nd try)
- To: ddsinc09 at ix dot netcom dot com
- Subject: Re: Fixinc and mvme328.h (2nd try)
- From: Manfred Hollstein <manfred at s-direktnet dot de>
- Date: Sat, 23 Jan 1999 19:26:21 +0100 (MET)
- Cc: egcs at egcs dot cygnus dot com, law at cygnus dot com, robertlipe at usa dot net
- References: <11546.915788304@hurl.cygnus.com><13979.13087.166270.809322@sls5gj.stgl.sel.alcatel.de><369B788A.A0EEE5A2@datadesign.com><13979.31135.891261.272909@sls5gj.stgl.sel.alcatel.de><13980.26518.531798.590317@sls5gj.stgl.sel.alcatel.de><369CC04A.F26D49AF@datadesign.com><13983.3546.80714.612766@sls5gj.stgl.sel.alcatel.de><13984.32018.881755.844159@saturn.hollstein.net><34C4BE50.B25B8380@datadesign.com><13989.63295.585987.609277@sls5gj.stgl.sel.alcatel.de>
- Reply-To: manfred at s-direktnet dot de
On Wed, 20 January 1999, 16:37:27, manfred@s-direktnet.de wrote:
> > I believe you need another test.
> > You cannot emulate the context of the derived header files
> > from the command line in this fashion. By my understanding,
> > in the processing of your test, the compiler first tried
> > to open "`pwd`/include/sys/" '+' "sys/m328sio.h" (the directory
> > of the <sys/mvme328.h> plus the file name it included with the
> > '"' construct). That failed silently. It then tried to open
> > "`pwd`/include/" '+' "sys/m328sio.h" (the path specified with
> > the -I option, plus the file name). That succeeded. Here is how
> > to test the problem:
> >
[...]
Here's another test:
1. Create the two files "/usr/include/sys/mvme328.h" and "/usr/include/sys/m328sio.h"
2. Call "gcc -c -H t.c" and you'll see:
/usr/include/sys/mvme328.h
/usr/include/sys/m328sio.h
Actually, "strace" shows how gcc behaves:
$ strace -o log -f -e trace=open gcc -c t.c
The particular lines in question contain:
1225 open("/tools/gnu/include/sys/mvme328.h", O_RDONLY) = -1 ENOENT (No such file or directory)
1225 open("/tools/gnu/lib/gcc-lib/i586-linux/egcs-2.93.02/include/sys/mvme328.h", O_RDONLY) = -1 ENOENT (No such file or directory)
1225 open("/usr/include/sys/mvme328.h", O_RDONLY) = 5
1225 open("/usr/include/sys/sys/m328sio.h", O_RDONLY) = -1 ENOENT (No such file or directory)
1225 open("/tools/gnu/include/sys/m328sio.h", O_RDONLY) = -1 ENOENT (No such file or directory)
1225 open("/tools/gnu/lib/gcc-lib/i586-linux/egcs-2.93.02/include/sys/m328sio.h", O_RDONLY) = -1 ENOENT (No such file or directory)
1225 open("/usr/include/sys/m328sio.h", O_RDONLY) = 5
This is indicating, that your assumption is correct, but the file is
still found via gcc's STANDARD_INCLUDE_DIR ("/usr/include").
I believe, fixincl needs to be extended to behave similarly, but with
its STANDARD_INCLUDE_DIR being the initial start directory.
[...]
> >
> >
> > I think the correct thing is to fix the #include statement.
> > I do not know if the correct fix is
> >
> > #include "m328sio.h"
> > or
> > #include <sys/m328sio.h>
> >
> > The former is precisely correct.
> > Either should do it.
> > If the latter breaks, then you must have file name conflicts
> > that have incompatible contents. Unlikely at best.
> >
> > It seems to me that there is such a fix for one of the oddball
> > "fixinc.*" files, but I may be misremembering.
> >
>
> I'll look into them.
I didn't find such a fix; but as we know now, fixincl ought be able to
properly parse even such admittedly bogus include files.
manfred