This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Shouldn't fixincludes remove assert.h instead of trying to fix it?


	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
assert.h file.

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.

Jim


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]