adding 'g++-v3/cshadow' to cpp search path...

brent verner
Wed Aug 23 14:39:00 GMT 2000

On 23 Aug 2000 at 15:14 (-0500), Loren James Rittle wrote:
| In article < >,
| brent verner <> writes:
| > I'm setting this up so the shadow directory, tentatively named
| > cshadow, will contain _all_ shadowed headers (from shadow and cshadow 
| > from the current libstdc++-v3 build) and live within the current
| > installed g++-v3 include directory. It should be very simple to 
| > change the name from cshadow, however.
| Hi Brent,
| My comments are triggered off the phrase: ``current installed g++-v3
| include directory''.

yes, that was horribly phrased... please let me try again :)

   I'm setting this up so the shadow directory, tentatively named
   cshadow, will contain the combined set of files from
   ${srcdir}/libstdc++-v3/shadow and
   and be installed as ${install_prefix}/include/g++-v3/cshadow.
   It should be very simple to change the name from cshadow, however.

  ( of course, we need to modify the libstdc++-v3 install to _not_
    install these until the cshadow headers work [which I failed to
    suggest in the original message], else we'll have _lots_ of 
    support emails saying 'just delete the cshadow dir' )

| (1) Any solution *must* allow checking the build tree in-place before
|     final installation.

ACK. building and testing specifies '-nostdinc++ -I ...' for its compile
commands, AFAICT - but I will verify my assumptions, which causes the 
cpp at 'make check' time to _not_ search any of the standard (c++ 
specific) include locations. my change _should not_ affect any current 
behavior of the compiler build or libstdc++-v3 test.

| (2) It must not matter if a previous version of gcc is installed in
|     the target location (as expressed by --prefix and the more exotic
|     configure arguments).
I have made 'check' from the hacked g++ build, with no failures due
to _my totally broken_ includes in ${prefix}/g++-v3/cshadow being
included. after install, the broken headers are found (if they are
there in g++-v3/cshadow) and almost nothing will compile.
| (3) Other than getting files from a different directory, the fully
|     bootstrapped compiler must behave the same before and after
|     installation.

this has been my observation so far using the cshadow-enabled g++/cpp
moving the g++-v3/cshadow directory out of the search path allows
things to compile normally.

| (4) Merely building a new compiler must not affect any installed
|     compiler.

?? not sure how to address this.

I summarize the changes^H that my patch currently makes:

     adds a standard c++ include directory of
     ${prefix}/g++-v3/${cshadow} to be searched by cpp
     before the ${prefix}/g++-v3 include directory.
     as with ${prefix}/g++-v3, this directory is not
     searched when -nostdinc++ is specified to cpp

| FYI, when I was trying to resolve the -I mess last time, Jeff Law said
| that it is OK to create a staging directory in the build tree that
| mirrors the final install location, if you need to.  Sorry for being
| so wordy, but you asked for comments before you do work in this
| area...

cool. thanks for this info, I'll (next try to) have a staged include
directory created under the ${build_dir}, and remove 
-I${src_dir}/shadow from the compile lines for libstdc++-v3

| Final meta comment: I wouldn't mind seeing all the -I hackery going
| away (including all that I last added ;-) by seeing a fully staged
| version of include being built.  However, it is not my place to make
| this decision.

what -I hackery are you referring to?

oh heck, I'll make a patch... all they can do is call me a monkey and
reject it -- neither of which hurt to terribly bad, plus I'll learn
quite a bit along the way :)  I agree that a staged include directory
will make the build/install a bit cleaner.

Thank you for your input.


Damon Brent Verner                        o      _     _         _
Cracker Jack® Surprise Certified  _o     /\_   _ \\o  (_)\__/o  (_)                _< \_   _>(_) (_)/<_    \_| \   _|/' \/               (_)>(_) (_)        (_)   (_)    (_)'  _\o_

More information about the Libstdc++ mailing list