This is the mail archive of the
mailing list for the GCC project.
Re: Shouldn't fixincludes remove assert.h instead of trying to fix it?
- To: Manfred Hollstein <manfred at s-direktnet dot de>
- Subject: Re: Shouldn't fixincludes remove assert.h instead of trying to fix it?
- From: Jim Wilson <wilson at cygnus dot com>
- Date: Thu, 19 Mar 1998 15:09:56 -0800
- cc: egcs-bugs at cygnus dot com, Manfred dot Hollstein at ks dot sel dot alcatel dot de
Why not simply install it in both directories?
That doesn't quite work. Consider the case of a cross compiler using newlib.
Newlib has its own assert.h file, and we would like to use it. Currently,
both newlib and gcc's assert.h file install into $(TOOLDIR)/include. Newlib
installs the file unconditionally. Gcc installs the file only if the file
does not already exist, or if the old file was installed by gcc. Hence, no
matter what order we install newlib and gcc, we always end up with newlib's
However, if we install assert.h in the $(libsubdir)/include directory also,
then we will get gcc's assert.h file instead of newlib's assert.h file,
because $(libsubdir)/include is searched before $(TOOLDIR)/include.
There is a similar problem with GNU libc, which also has its own assert.h
file that we want to use.
This could work if we made it conditional on FIXINCLUDES though. The only
cases where gcc's assert.h file is a problem don't run FIXINCLUDES anyways,
and the cases where gcc's assert.h file would help are the cases where we
must run FIXINCLUDES. So if we install assert.h in $(libsubdir)/include
if and only if FIXINCLUDES != Makefile.in then we should be covered.
Alternatively, if we fix the search order for header files then we can make
the problem go away, but that is a much more involved change.