Installation of libstdc++-v3 headers

[Michael Matz <matz at suse dot de>]

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).

In the gcc/ dir libstdcxx_incdir _is_ AC_SUBSTed, and hence cc1plus gets
the full paths in which it will search.  Ergo compiling a C++ program will
most probably fail (and does for me), because not finding includes.

To fix this, top-level configure.in either needs to do:

gxx_include_dir='${prefix}/include/'"${libstdcxx_incdir}"

or, better to add the AC_SUBST equivalent at the end:
+s%@libstdcxx_incdir@%${libstdcxx_incdir}%

And of course add a 'libstdcxx_incdir=@libstdcxx_incdir@' at the
Makefile.in.

If I read the ChangeLog correctly this state exists since five months, so
I really wonder why noone noticed that yet.


Ciao,
Michael.