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

[Manfred Hollstein <manfred at s-direktnet dot de>]

On Sat, 10 October 1998, 22:19:07, law@cygnus.com wrote:

 > 
 >   In message <13855.33419.398235.145221@saturn.hollstein.net>you write:
 >   >  > > The source of the problem is: the root directory for locating files is
 >   >  > > $(libsubdir), and this usually *does not exist while you're building a
 >   >  > > new snapshot*,   hence assemblers, linkers,   binutils, include  files
 >   >  > > (forgot anything?)  won't be found at build time.
 >   >  > 
 >   >  > But they aren't currently found anyway, and they weren't found in the
 >   >  > install tree before.  Moreover, I'm not trying to fix this problem,
 >   >  > I'm fixing *another* problem, so rejecting this patch because it does
 >   >  > not fix the binaries-not-found problem is unfair :-)
 >   > 
 >   > I'm sorry, my intention was not to attack anybody or to reject your patch;
 >   > if it sounded this way, I honestly apologize! I was only surprised (and
 >   > perhaps somewhat angry) to see how many working things had been broken
 >   > by this small $(unlibsubdir) patch :-)
 > Can someone please summarize the problems we need to address?
 > 
 > 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"?

 > 
 > But I may not understand the problems fully, so please explain
 > both problems we're having in detail.

I'll give it a try, see below.

 > 
 >   >  > In order to fix the binaries-not-found problem, wouldn't it be enough
 >   >  > to add another -B switch to GCC_FOR_TARGET, as well as to CC for
 >   >  > stages after stage1?
 >   > 
 >   > I believe this would solve the problem, indeed.
 > No, that's not the right approach.  If that's required, then the problem lies
 > elsewhere.
 > 
 > jeff

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_prefix) | 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 Alexandre's
    patch does, to simply:

        - define gxx_include_dir correctly in the configure script, and
	- use -DGPLUSPLUS_INCLUDE_DIR=\"$(gxx_include_dir)\" in Makefile.in

 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?

Now I hear you asking, "why then didn't this happen over the last years within
Cygnus?".  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?

I believe, that Alexandre's patch extended by a fix for cpplib.o + the additional
"-B..." flag will solve this problem.

manfred