Re: latest snapshot won't find C++ header files

[Jeffrey A Law <law at cygnus dot com>]

  In message <13856.36883.998239.234080@saturn.hollstein.net>you write:
  >  > Again, it is my believe that changing configure.in to define unlibsubdir
  >  > to "." in those cases where it can not be made to work should fix both
  >  > problems.
  > 
  > But, how do you decide "where it can not be made to work"?
Anytime the user specifies an explicit directory for include files or 
depending on relationships between $prefix and $exec_prefix for example.


  > Actually, we are having two problems:
  > 
  >  1. C++ include files will not be found, or will be installed in a different
  >     directory, where cpp isn't looking for; the reason behind this is, that
  >     both "cccp.o" and "cpplib.o" are using a hard-coded
  > 
  > 	 -DGPLUSPLUS_INCLUDE_DIR=\"$(libsubdir)/$(unlibsubdir)/..`echo $(exec_p
  > refix) | sed -e 's|^$(prefix)||' -e 's|/[^/]*|/..|g'`/include/g++\"
  > 
  >     instead of considering the fact, that the user might have given
  > 
  > 	 "--with-gxx-include-dir=/any/where" or
  > 	 "--enable-version-specific-runtime-libs"
  > 
  >     as configure arguments.  Once the user installs this compiler, the C++
  >     include files will be copied into the appropriate directory (as this is
  >     done correctly by the libio/libstdc++/libg++ Makefiles), but "cpp"
  >     will not look where it'd be appropriate.  The fix would be, as Alexandr e's
  >     patch does, to simply:
Right.  Agreed.


  >  2. The second problem arises from the fact, that, provided you're building
  >     a *new* snapshot, $(libsubdir) usually *does not already* exist! If
  >     now $(libsubdir)/$(unlibsubdir) with unlibsubdir=../../.. is used to
  >     locate "as", "ld", "include" (did I miss anything?), the just built
  >     "xgcc" will simply fail and revert to its "second" default, e.g. using
  >     "/usr/ccs/bin/as" on HP-UX or Solaris.  Creating an empty $(libsubdir)
  >     before "make bootstrap" would cure this, but simply adding
  >     "-B${exec_prefix}/${target}/bin" to the appropriate ..._CFLAGS might
  >     be the better solution (again, this is, what Alexandre suggested in his
  >     email).
  > 
  > Is that clear enough? Do you need more details?
Thanks, I managed to wrap my head around this one yesterday.

  > Now I hear you asking, "why then didn't this happen over the last years wit 
  > within Cygnus?".
Yes, I've been asking myself that question :-)  I also found hte answer
yesterday.  The difference is we always build everything together and thus in
our builddir we have links to the newly built assembler & linker in the
gcc objdir.

  > Well, the fact that we're now needing particular binutils versions
  > is quite new (exception handling etc.), perhaps this wasn't the case with
  > Cygnus' earlier gcc versions; or perhaps you have these particular versions
  > installed "by accident" at their "second" default location?
Na.  It's always been the case on some platforms.  Believe me, if gcc didn't
find gas at build time, certain platforms will blow up.  Nothing new.

jeff