Re: Unable to build libstdc++-v3

[Phil Edwards <pedwards at disaster dot jaj dot com>]

Long-winded message ahead.  Take a deep breath before reading.


On Thu, Aug 24, 2000 at 08:18:03AM +0200, Ronald Fischer wrote:
> > Well, building libstdc++-v[23] should happen during the 'make bootstrap'
> > step, I believe.  
> 
> It *should*, but it did not. That's why Benjamin suggested to me doing a
> separate 'make all-target-libstdc++-v3'.

Now I see what you're saying (been having to catch up on mailing lists).
This is all due to the problem below.

[lots of "make <foo> not doing a thing" snipped]


> > > grep: illegal option -- q
> > > Usage: grep -hblcnsviw pattern file . . .
> > 
> > Ah.  Crumbs.  The native Solaris grep doesn't take -q like POSIX says.
> > This is what happens when the native /usr/bin binaries are in the PATH
> > before the POSIX /usr/xpg4/bin binaries.  I'll try to adjust for that.
> 
> I put /usr/xpg4/bin in front of my path and again do a 'make
> all-target-libstdc++-v3'. Now the make runs considerably longer, does a
> *lot* of "checking for ... declaration" stuff,

This is why none of the make invocations were working.  All of the targets
you were trying (bootstrap, all, all-target-libstdc++-v3, etc) know that
the library must be configured before it can be compiled, and it must be
compiled before anything (including headers) can be installed.

So every time you tried to make /anything/ it would try to run the configure
script.  Our configure script checks early on that GNU make is available
somewhere.  In doing so, it uses some POSIX behavior of grep.  Unfortunately,
the basic Solaris grep fails in this respect.  So the library configure
would bomb.  Changing your PATH fixed that and allowed stuff to go further.

A couple side notes:

  1)  I have a patch to the configure setup that will do that PATH change
  on Solaris machines.  I've also added a bit in the "required tools"
  section of the documentation that Solaris users should have that package
  installed (it is an optional one, but it's not large and comes on the CD).

  2)  I am trying to think of a way to detect GNU make that doesn't
  depend on POSIX ("portable", hah) behavior.  And that doesn't also suck.
  That way we wouldn't need to mess with the PATH.

  3)  [Solaris trivia]  The duplication of programs in /usr/bin and
  /usr/xpg4/bin happens when there is a conflict between POSIX or X/Open
  option behavior and traditional Solaris behavior.  There is no conflict
  with "grep -q" (i.e., there is no native -q to conflict with) so I will
  be submitting a request to Sun that they implement such, since there is
  no reason not to.  Maybe we can make Solaris 9 less bad in this respect.

  4)  Somebody more familiar with the build tools will have to answer this
  one:  when lib-v3's configure bombs out with an "exit 1" why does the
  top-level make silently keep going?


> /pro/prornc/gcc000807/egcs-20000807/libstdc++-v3/libio/libio.h:60:25:
> sys/cdefs.h: No such file or directory

Known problem.  You're now current with the rest of us.  :-)

(Can somebody tell me what that extra ":25:" business after the line number
in the error message is?)


-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.