This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Installation of libstdc++-v3 headers
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Michael Matz <matz at suse dot de>
- Cc: gcc at gcc dot gnu dot org, bkoz at redhat dot com
- Date: Thu, 14 Nov 2002 11:57:37 -0500
- Subject: Re: Installation of libstdc++-v3 headers
- References: <Pine.LNX.4.33.0211141514260.32309-100000@wotan.suse.de>
On Thu, Nov 14, 2002 at 03:29:20PM +0100, Michael Matz wrote:
> Hi Benjamin, others,
>
> I just went to current head for my development, and for the first time
> since some months also tried the C++ part of it with a real install. I
> think it's broken, in that the C++ headers are installed into
> ${prefix}/include/ directly instead of into
> ${prefix}/include/c++/3.3 .
> But the cc1plus itself _does_ search the .../c++/3.3/ directory. I've
> configured the thing with
> ..../configure --prefix=/spec/ra/inst --enable-languages=c,c++,f77
>
> The reason for the breakage is, that in toplevel/configure.in
> $gxx_include_dir is set to '${prefix}/include/${libstdcxx_incdir}', which
> means, that libstdcxx_incdir is _not_ substituted at this point. Ergo the
> Makefile (after configuring) contains
>
> gxx_include_dir=${prefix}/include/${libstdcxx_incdir}
>
> The problem of course is, that libstdcxx_incdir is not AC_SUBSTed (Ok,
> the equivalent which is used in the toplevel) in the toplevel
> configure.in, which in turn means, in the Makefile it remains empty. As
> ${gxx_include_dir} is passed down to the submakes, also the
> install-data-local in ${target}/libstdc++-v3/include gets that definition
> (instead of the local one, which would probably be correct).
I've had this patch in my local tree for some time, and been wondering
how no one else gets affected by the problem...
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer