Re: Cannot build both gcc and new snapshot on i686-pc-linux-gnu

[Benjamin Kosnik <bkoz at cygnus dot com>]

Russell, thanks. This stuff is in now.


2000-03-27  Russell Davidson  <russell@ehess.cnrs-mrs.fr>

	* testsuite/23_containers/multiset.cc (main): Clean up for namespaces.
	* testsuite/22_locale/ctype_char_members.cc: And here.
	* testsuite/27_io/streambuf.cc (streambuf): And here.
	* testsuite/27_io/ostream_inserter_char.cc (test06): And here.
	* testsuite/27_io/istream_unformatted.cc (test05): And here.
	* testsuite/27_io/istream_extractor_arith.cc: And here.
	* testsuite/27_io/ios_manip_basefield.cc (test02): And here.
	* testsuite/27_io/ios_base_members_static.cc: And here.
	* bits/std_climits.h (_CPP_CLIMITS): Fix typo.


This part, however, has not been addressed:

>> I fiddled with everything in mkcheck, and finally ran the problem
>> to earth. It is that mkcheck passes to the compiler (in INC_PATH)
>> an explicit path for the g++-v3 include files. I would argue that
>> this is an error, for the following reasons:

>> By passing "-I prefixdir/include/g++-v3" explicitly to the
>> compiler, this directory is passed twice, since the compiler knows
>> to look there anyway.  This mucks up a number of #include_next
>> preprocessor directives. For instance, with
>> 17_intro/header_fstream.cc, at one stage in reading the included
>> files, bits/std_ios.h includes bits/std_exception.h. This file in
>> turn does #include_next <exception> and then there is trouble,
>> because it just turns round and looks at our own exception, which
>> sends it back to bits/std_exception.h, which is not read because of
>> the guard. This happens because the "next" directory is a repeat of
>> the one we are already in.  However, if we do not specify the
>> include directory explicitly, the compiler knows to look there
>> anyway, and then moves on to what is really needed, namely
>> prefixdir/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/include/exception
>> The same thing happens with bits/std_new.h and bits/std_typeinfo.h.

Thanks for tracking this down. What you've described is a correct
assessment of the problem. I'm not quite sure how to fix it though:
the include directory has to be included for compliers that are not
installed and already part of a PATH. 

I dunno. Perhaps the "mkcheck" mechanism has outlived it's usefullness
and should be replaced by a more automated approach, like dejagnu. 



-benjamin