From mboxrd@z Thu Jan  1 00:00:00 1970
From: Manfred Hollstein <manfred@s-direktnet.de>
To: law@cygnus.com
Cc: jbuck@synopsys.com, drepper@cygnus.com, egcs@cygnus.com
Subject: Re: once we have cpplib... 
Date: Thu, 16 Apr 1998 10:51:00 -0000
Message-id: <13622.2001.164373.946740@slsvhmt>
References: <199804100044.RAA11888@atrus.synopsys.com> <29460.892182063@hurl.cygnus.com>
X-SW-Source: 1998-04/msg00633.html

On Thu, 9 April 1998, 22:21:03, law@cygnus.com wrote:

 > 
 >   In message < 199804100044.RAA11888@atrus.synopsys.com >you write:
 >   > > > Persnally, I don't see this as having much importance.  Do we we really
 >   > > > support the -V option?  Cygnus has always recommended against its use.
 >   > > 
 >   > > I think it is essential.  I have many old compilers lying around since
 >   > > I build and install egcs frequently.  If a version is broken I must be
 >   > > easy to use an old version.
 >   > 
 >   > Unfortunately -V switches compilers but doesn't switch libstdc++, so
 >   > in practice I've had to use distinct --prefix values to keep multiple
 >   > compilers around.
 > So, I'll bring it up again, do we want to move the g++ header
 > files and libraries into $libsubdir?
 > 
 > We've discussed it at length in the past; I don't remember ever
 > reaching any decision.

I'd greatly appreciate  if the stuff will  be installed in $libsubdir,
because this is the way I've installed it since gcc-2.2.2 (or so).

If we'll be going to change installation rules, where should
_G_config.h be installed? Currently it goes into
${prefix}/${target}/include, but I think it should be installed in
${libsubdir}/include (or ${gxx_include_dir}), right?!

Anyway, if nobody  else has a patch already  I'll preparing  one which
will provide this:

  1. Change the default for g++ header installation from
     ${prefix}/include/g++ to ${libsubdir}/include/g++
  2. Install _G_config.h in ${libsubdir}/include.
  3. Install runtime libs (libstdc++.*) in ${libsubdir}
     resp. subdirectories for multilib configurations.

Once  3. is active,  I'm afraid we'll be  receiving lots of complaints
from Linux users  about   ld.so no  longer   finding libstdc++.so.2.8,
though :-(

This brings back the `-rpath'  question. How about gcc/collect2 adding
it if libstdc++.so is found via one of the `standard directories' from
the specs file?

manfred