This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: How do I run "make check" in gcc with libstdc++-v3?
- To: hjl at lucon dot org
- Subject: Re: How do I run "make check" in gcc with libstdc++-v3?
- From: Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>
- Date: Tue, 16 May 2000 00:19:39 -0500 (CDT)
- CC: gcc at gcc dot gnu dot org
- References: <200005152223.RAA39188@latour.rsch.comm.mot.com> <20000515153549.A13740@lucon.org>
- Reply-to: rittle at rsch dot comm dot mot dot com
In article <20000515153549.A13740@lucon.org>,
"H . J . Lu" <hjl@lucon.org> writes:
> On Mon, May 15, 2000 at 05:23:33PM -0500, Loren James Rittle wrote:
>> > Many g++ tests in gcc failed since dejagnu couldn't find libstdc++
>> > in libstdc++-v3. Did I miss something?
>> Yup, you need to apply a system dependent patch to libgloss.exp (on my
>> system it located in /usr/local/share/dejagnu).
>> I posted comments and a version of the patch that works for me in:
>> http://sourceware.cygnus.com/ml/libstdc++/2000-q2/msg00245.html
>> It is very important to note that I have found NO patch which allows
>> checking g++ without first installing everything. This is a clear
>> regression over libstdc++-v2.
> Have you tried
> http://www.lucon.org/gcc/3.0/gcc-3.0-libstc++-v3.patch
I have not tried your patch yet. However, I did look at the
technique. You extended libstdc++-v3/mkcheck to report various
configuration information back to other parts of the build tree.
Assuming we can't simplify the build process to completely localize
such information, I suppose your technique is OK.
I especially like that you figured out how to override libgloss.exp.
> It works for me.
I'm not sure your patch is really working for you since you are still
seeing many errors related to #include_next usage (you reported this
in another message recently). The only ways I see to get rid of those
failures is (1) to find libstdc++-v3 headers with -isystem instead of
-I while testing [good luck finding the right order for -isystem
arguments given the current interactions with -B] or (2) to arrange
for the headers to be pre-staged somewhere in $(obj) as they will
eventual be installed in $prefix so ``$(obj)/gcc/g++ -B$(obj)/gcc/''
works without needing any extra -I parameters during testing [even
this approach isn't as easy as it should be since -B blindly installs
a new header path that conflicts with the "right" thing for C++].
Regards,
Loren