Re: Top-level Makefile

Re: Top-level Makefile

[Richard Kenner]

    Being too slow when processing certain constructs present in
    libstdc++-v3/configure is arguably a performance bug in whatever shell
    you're running, and setting CONFIG_SHELL to some more efficient shell
    is a possible work-around.

I did

	setenv CONFIG_SHELL /usr/local/bin/bash
	setenv SHELL /usr/local/bin/bash

and reran configure and exactly the same thing happened.

I don't see how either would override the "#/bin/sh", though.

I think this needs to be written in a way that shells that people are
goign to be using work reasonably.  Users aren't going to tolerate
configure times of nearly two hours any more than I am.

Re: Top-level Makefile

[David Edelsohn]

>>>>> Richard Kenner writes:

Richard> setenv CONFIG_SHELL /usr/local/bin/bash
Richard> setenv SHELL /usr/local/bin/bash

Richard> and reran configure and exactly the same thing happened.

	Note that I use

$ make SHELL=/usr/local/bin/bash CONFIG_SHELL=/usr/local/bin/bash ... bootstrap

Setting the appropriate environment variables should be equivalent with
GNU Make, but I am not sure.

David

Re: Top-level Makefile

[David Edelsohn]

>>>>> Richard Kenner writes:

Richard> setenv CONFIG_SHELL /usr/local/bin/bash
Richard> setenv SHELL /usr/local/bin/bash

Richard> and reran configure and exactly the same thing happened.

	Note that I use

$ make SHELL=/usr/local/bin/bash CONFIG_SHELL=/usr/local/bin/bash ... bootstrap

Setting the appropriate environment variables should be equivalent with
GNU Make, but I am not sure.

David

Re: Top-level Makefile

[Richard Kenner]

    Being too slow when processing certain constructs present in
    libstdc++-v3/configure is arguably a performance bug in whatever shell
    you're running, and setting CONFIG_SHELL to some more efficient shell
    is a possible work-around.

I did

	setenv CONFIG_SHELL /usr/local/bin/bash
	setenv SHELL /usr/local/bin/bash

and reran configure and exactly the same thing happened.

I don't see how either would override the "#/bin/sh", though.

I think this needs to be written in a way that shells that people are
goign to be using work reasonably.  Users aren't going to tolerate
configure times of nearly two hours any more than I am.

Re: Top-level Makefile

[Richard Kenner]

    Can you post the precise sequence of commands you are using, starting
    from an empty build directory?

Well I'm *not* starting from an empty build directory.  I'm doing
./config.status or explicitly rerunning configure.

Re: Top-level Makefile

[Zack Weinberg]

On Fri, Nov 30, 2001 at 09:56:05PM -0500, Richard Kenner wrote:
>     Can you post the precise sequence of commands you are using, starting
>     from an empty build directory?
> 
> Well I'm *not* starting from an empty build directory.  I'm doing
> ./config.status or explicitly rerunning configure.

Ah.  Of course David's trick won't work in that case.

However, if you _do_ start from an empty directory, I will be very
surprised if it doesn't.

For reference, this is the script I have sitting at the top of all my
source trees:

#! /bin/sh

srcdir=`dirname $0`
prefix=$HOME/install/${srcdir##*/}
set -ex
#DWARF=--with-dwarf2
#CHECK=--enable-checking
#CHECK=--disable-checking
THREADS=--enable-threads=posix
#SHARED=--enable-shared
#GETTEXT=--with-included-gettext
$srcdir/configure --prefix=$prefix \
	$DWARF $CHECK $THREADS $SHARED $GETTEXT >Lc 2>&1
/usr/bin/time make bootstrap >Lb 2>&1
/usr/bin/time make -k check  >Lk 2>&1

and when I say I bootstrapped the compiler I mean I ran this script
starting from an empty build directory.  It is my understanding that
this is the preferred way to do things.

Try sticking 

CONFIG_SHELL=/path/to/bash
SHELL=/path/to/bash
export SHELL CONFIG_SHELL

at the top of that script, and running it from your build dir, like this:

$ ../src/gcc/build-it

zw

Re: Top-level Makefile

[Zack Weinberg]

On Fri, Nov 30, 2001 at 09:56:05PM -0500, Richard Kenner wrote:
>     Can you post the precise sequence of commands you are using, starting
>     from an empty build directory?
> 
> Well I'm *not* starting from an empty build directory.  I'm doing
> ./config.status or explicitly rerunning configure.

Ah.  Of course David's trick won't work in that case.

However, if you _do_ start from an empty directory, I will be very
surprised if it doesn't.

For reference, this is the script I have sitting at the top of all my
source trees:

#! /bin/sh

srcdir=`dirname $0`
prefix=$HOME/install/${srcdir##*/}
set -ex
#DWARF=--with-dwarf2
#CHECK=--enable-checking
#CHECK=--disable-checking
THREADS=--enable-threads=posix
#SHARED=--enable-shared
#GETTEXT=--with-included-gettext
$srcdir/configure --prefix=$prefix \
	$DWARF $CHECK $THREADS $SHARED $GETTEXT >Lc 2>&1
/usr/bin/time make bootstrap >Lb 2>&1
/usr/bin/time make -k check  >Lk 2>&1

and when I say I bootstrapped the compiler I mean I ran this script
starting from an empty build directory.  It is my understanding that
this is the preferred way to do things.

Try sticking 

CONFIG_SHELL=/path/to/bash
SHELL=/path/to/bash
export SHELL CONFIG_SHELL

at the top of that script, and running it from your build dir, like this:

$ ../src/gcc/build-it

zw

Re: Top-level Makefile

[Richard Kenner]

    Can you post the precise sequence of commands you are using, starting
    from an empty build directory?

Well I'm *not* starting from an empty build directory.  I'm doing
./config.status or explicitly rerunning configure.

Re: Top-level Makefile

[Richard Kenner]

	Note that I use

    $ make SHELL=/usr/local/bin/bash CONFIG_SHELL=/usr/local/bin/bash ... bootstrap

    Setting the appropriate environment variables should be equivalent with
    GNU Make, but I am not sure.

You lost me.  I was doing configure, not make.

Re: Top-level Makefile

[Zack Weinberg]

On Fri, Nov 30, 2001 at 08:39:00PM -0500, Richard Kenner wrote:
> 	Note that I use
> 
>     $ make SHELL=/usr/local/bin/bash CONFIG_SHELL=/usr/local/bin/bash ... bootstrap
> 
>     Setting the appropriate environment variables should be equivalent with
>     GNU Make, but I am not sure.
> 
> You lost me.  I was doing configure, not make.

The libstdc++ configure script shouldn't run during initial configure;
it's target-only.  It is supposed to be run during the course of the
"make bootstrap" from top level.

Can you post the precise sequence of commands you are using, starting
from an empty build directory?

zw

Re: Top-level Makefile

[Zack Weinberg]

On Fri, Nov 30, 2001 at 08:39:00PM -0500, Richard Kenner wrote:
> 	Note that I use
> 
>     $ make SHELL=/usr/local/bin/bash CONFIG_SHELL=/usr/local/bin/bash ... bootstrap
> 
>     Setting the appropriate environment variables should be equivalent with
>     GNU Make, but I am not sure.
> 
> You lost me.  I was doing configure, not make.

The libstdc++ configure script shouldn't run during initial configure;
it's target-only.  It is supposed to be run during the course of the
"make bootstrap" from top level.

Can you post the precise sequence of commands you are using, starting
from an empty build directory?

zw

Re: Top-level Makefile

[Bryce McKinlay]

Richard Kenner wrote:

>	Note that I use
>
>    $ make SHELL=/usr/local/bin/bash CONFIG_SHELL=/usr/local/bin/bash ... bootstrap
>
>    Setting the appropriate environment variables should be equivalent with
>    GNU Make, but I am not sure.
>
>You lost me.  I was doing configure, not make.
>
"configure" for subdirectories like gcc, libstdc++, libjava, etc, is 
invoked by the top-level "make".

regards

Bryce.

Re: Top-level Makefile

[Bryce McKinlay]

Richard Kenner wrote:

>	Note that I use
>
>    $ make SHELL=/usr/local/bin/bash CONFIG_SHELL=/usr/local/bin/bash ... bootstrap
>
>    Setting the appropriate environment variables should be equivalent with
>    GNU Make, but I am not sure.
>
>You lost me.  I was doing configure, not make.
>
"configure" for subdirectories like gcc, libstdc++, libjava, etc, is 
invoked by the top-level "make".

regards

Bryce.

Re: Top-level Makefile

[David Edelsohn]

>>>>> Richard Kenner writes:

> Note that I use
> $ make SHELL=/usr/local/bin/bash CONFIG_SHELL=/usr/local/bin/bash ... bootstrap

> Setting the appropriate environment variables should be equivalent with
> GNU Make, but I am not sure.

Richard> You lost me.  I was doing configure, not make.

	As others have mentioned, "configure" is run at different times.
The first manual configure is for the build of the compiler itself.  Then
"make bootstrap" or "make all" in the top-level runs configure implicitly
to set up the target libraries based on the target compiler just built.
libstdc++-v3 is one of those directories in which "configure" is run by
Make.

	The upshot is that you need to specify the shell to Make so that
it is used by the libstdc++-v3 configure.

David

Re: Top-level Makefile

[David Edelsohn]

>>>>> Richard Kenner writes:

> Note that I use
> $ make SHELL=/usr/local/bin/bash CONFIG_SHELL=/usr/local/bin/bash ... bootstrap

> Setting the appropriate environment variables should be equivalent with
> GNU Make, but I am not sure.

Richard> You lost me.  I was doing configure, not make.

	As others have mentioned, "configure" is run at different times.
The first manual configure is for the build of the compiler itself.  Then
"make bootstrap" or "make all" in the top-level runs configure implicitly
to set up the target libraries based on the target compiler just built.
libstdc++-v3 is one of those directories in which "configure" is run by
Make.

	The upshot is that you need to specify the shell to Make so that
it is used by the libstdc++-v3 configure.

David

Re: Top-level Makefile

[Richard Kenner]

	Note that I use

    $ make SHELL=/usr/local/bin/bash CONFIG_SHELL=/usr/local/bin/bash ... bootstrap

    Setting the appropriate environment variables should be equivalent with
    GNU Make, but I am not sure.

You lost me.  I was doing configure, not make.

Re: Top-level Makefile

[Richard Kenner]

    - Put "set -x" at the top of the configure script, then post the last
      thirty or so lines of the output once it gets stuck.

+ echo nan.h
ac_safe=nan_h
+ echo checking for nan.h... \c
checking for nan.h... + echo configure:5085: checking for nan.h
+ echo ${ac_cv_header_nan_h+set}
+ eval test "${ac_cv_header_nan_h+set}" = set
+ test  = set
+ cat
ac_try=$CPP $CPPFLAGS conftest.c >/dev/null 2>conftest.out
+ eval echo configure:5095: "$CPP $CPPFLAGS conftest.c >/dev/null 2>conftest.out
"
+ echo configure:5095: gcc -E  conftest.c >/dev/null 2>conftest.out
+ grep -v ^conftest.c$
+ grep -v ^ *+ conftest.out
ac_err=
+ test -z
+ rm -rf conftest.c conftest.out
+ eval ac_cv_header_nan_h=yes
ac_cv_header_nan_h=yes
+ rm -f conftest*
+ echo $ac_cv_header_nan_h
+ eval test "$ac_cv_header_nan_h" = yes
+ test yes = yes
+ echo yes
yes
+ sed y%abcdefghijklmnopqrstuvwxyz./-%ABCDEFGHIJKLMNOPQRSTUVWXYZ___%
+ echo nan.h
ac_tr_hdr=HAVE_NAN_H
+ cat
+ sed y%./+-%__p_%
+ echo ieeefp.h
ac_safe=ieeefp_h
+ echo checking for ieeefp.h... \c

So it's not doing a whole lot, but doing it slowly: there are delays of
perhaps 5-10 seconds between a number of those lines.

    - Look in all the tmp directories your system has (/tmp, /usr/tmp,
      /var/tmp, etc) and see if there's a large number of scratch files
      created by the configure script.

Yes, 605 of them.

Re: Top-level Makefile

[Zack Weinberg]

On Fri, Nov 30, 2001 at 05:59:39AM -0500, Richard Kenner wrote:
>     - Put "set -x" at the top of the configure script, then post the last
>       thirty or so lines of the output once it gets stuck.
> 
> + echo nan.h
> ac_safe=nan_h
> + echo checking for nan.h... \c
> checking for nan.h... + echo configure:5085: checking for nan.h
> + echo ${ac_cv_header_nan_h+set}
> + eval test "${ac_cv_header_nan_h+set}" = set
> + test  = set
> + cat
> ac_try=$CPP $CPPFLAGS conftest.c >/dev/null 2>conftest.out
> + eval echo configure:5095: "$CPP $CPPFLAGS conftest.c >/dev/null 2>conftest.out
> "
...
> 
> So it's not doing a whole lot, but doing it slowly: there are delays of
> perhaps 5-10 seconds between a number of those lines.

It would be useful to know which.  The cat commands are most likely,
but something else might be going on.

>     - Look in all the tmp directories your system has (/tmp, /usr/tmp,
>       /var/tmp, etc) and see if there's a large number of scratch files
>       created by the configure script.
> 
> Yes, 605 of them.

Okay, so that's a strong case for being the same problem rth and I
were looking at last May.  I'll send you a hack to try sometime
tomorrow.

zw

Re: Top-level Makefile

[Zack Weinberg]

On Fri, Nov 30, 2001 at 05:59:39AM -0500, Richard Kenner wrote:
>     - Put "set -x" at the top of the configure script, then post the last
>       thirty or so lines of the output once it gets stuck.
> 
> + echo nan.h
> ac_safe=nan_h
> + echo checking for nan.h... \c
> checking for nan.h... + echo configure:5085: checking for nan.h
> + echo ${ac_cv_header_nan_h+set}
> + eval test "${ac_cv_header_nan_h+set}" = set
> + test  = set
> + cat
> ac_try=$CPP $CPPFLAGS conftest.c >/dev/null 2>conftest.out
> + eval echo configure:5095: "$CPP $CPPFLAGS conftest.c >/dev/null 2>conftest.out
> "
...
> 
> So it's not doing a whole lot, but doing it slowly: there are delays of
> perhaps 5-10 seconds between a number of those lines.

It would be useful to know which.  The cat commands are most likely,
but something else might be going on.

>     - Look in all the tmp directories your system has (/tmp, /usr/tmp,
>       /var/tmp, etc) and see if there's a large number of scratch files
>       created by the configure script.
> 
> Yes, 605 of them.

Okay, so that's a strong case for being the same problem rth and I
were looking at last May.  I'll send you a hack to try sometime
tomorrow.

zw

Re: Top-level Makefile

[Richard Kenner]

    - Put "set -x" at the top of the configure script, then post the last
      thirty or so lines of the output once it gets stuck.

+ echo nan.h
ac_safe=nan_h
+ echo checking for nan.h... \c
checking for nan.h... + echo configure:5085: checking for nan.h
+ echo ${ac_cv_header_nan_h+set}
+ eval test "${ac_cv_header_nan_h+set}" = set
+ test  = set
+ cat
ac_try=$CPP $CPPFLAGS conftest.c >/dev/null 2>conftest.out
+ eval echo configure:5095: "$CPP $CPPFLAGS conftest.c >/dev/null 2>conftest.out
"
+ echo configure:5095: gcc -E  conftest.c >/dev/null 2>conftest.out
+ grep -v ^conftest.c$
+ grep -v ^ *+ conftest.out
ac_err=
+ test -z
+ rm -rf conftest.c conftest.out
+ eval ac_cv_header_nan_h=yes
ac_cv_header_nan_h=yes
+ rm -f conftest*
+ echo $ac_cv_header_nan_h
+ eval test "$ac_cv_header_nan_h" = yes
+ test yes = yes
+ echo yes
yes
+ sed y%abcdefghijklmnopqrstuvwxyz./-%ABCDEFGHIJKLMNOPQRSTUVWXYZ___%
+ echo nan.h
ac_tr_hdr=HAVE_NAN_H
+ cat
+ sed y%./+-%__p_%
+ echo ieeefp.h
ac_safe=ieeefp_h
+ echo checking for ieeefp.h... \c

So it's not doing a whole lot, but doing it slowly: there are delays of
perhaps 5-10 seconds between a number of those lines.

    - Look in all the tmp directories your system has (/tmp, /usr/tmp,
      /var/tmp, etc) and see if there's a large number of scratch files
      created by the configure script.

Yes, 605 of them.

Re: Top-level Makefile

[Richard Kenner]

    make all does build with optimization, since it's assumed that this
    one is going to be installed.  make bootstrap builds stage1 without
    optimization.

OK, that makes sense.

    Try some more efficient shell, such as bash or at least ksh.

Well, the shell script has #!/bin/sh" in the first line, so that's the
one that's going to be used.  It needs to work reasonably with that one.

Re: Top-level Makefile

[Alexandre Oliva]

On Nov 29, 2001, kenner@vlsi1.ultra.nyu.edu (Richard Kenner) wrote:

>     Try some more efficient shell, such as bash or at least ksh.

> Well, the shell script has #!/bin/sh" in the first line, so that's the
> one that's going to be used.  It needs to work reasonably with that one.

This doesn't necessarily follow.  Solaris' /bin/sh, for example, has a
bug that causes it to *sometimes* crash while running ltconfig.  Being
too slow when processing certain constructs present in
libstdc++-v3/configure is arguably a performance bug in whatever shell
you're running, and setting CONFIG_SHELL to some more efficient shell
is a possible work-around.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Top-level Makefile

[Alexandre Oliva]

On Nov 29, 2001, kenner@vlsi1.ultra.nyu.edu (Richard Kenner) wrote:

>     Try some more efficient shell, such as bash or at least ksh.

> Well, the shell script has #!/bin/sh" in the first line, so that's the
> one that's going to be used.  It needs to work reasonably with that one.

This doesn't necessarily follow.  Solaris' /bin/sh, for example, has a
bug that causes it to *sometimes* crash while running ltconfig.  Being
too slow when processing certain constructs present in
libstdc++-v3/configure is arguably a performance bug in whatever shell
you're running, and setting CONFIG_SHELL to some more efficient shell
is a possible work-around.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Top-level Makefile

[David Edelsohn]

>>>>> Richard Kenner writes:

> Try some more efficient shell, such as bash or at least ksh.

Richard> Well, the shell script has #!/bin/sh" in the first line, so that's the
Richard> one that's going to be used.  It needs to work reasonably with that one.

	The shell is determined by target configure and substituted into
the script.

The problem I had with fastjar apparently has been fixed, but the major
problem is in configuring libstcv++v3.  Each of the following lines took 85
seconds, meaning the entire configure takes over an hour.  I'm on
alphaev56-dec-osfv4.0c.  The last time I reported this I was told it had been
fixed.  I see it has not ...

	This is because v3 saves and restores the state excessively which
some shells implement with temporary files.  I had a similar problem on
AIX.  I improved the situation on AIX by using Bash.

	I run Make with the following items in the incantation:

SHELL=/usr/gnu/bin/bash CONFIG_SHELL=/usr/gnu/bin/bash

and v3 configures in a human timescale again.

David

Re: Top-level Makefile

[Phil Edwards]

On Thu, Nov 29, 2001 at 11:07:12AM -0500, David Edelsohn wrote:
> 	This is because v3 saves and restores the state excessively which
> some shells implement with temporary files.  I had a similar problem on
> AIX.  I improved the situation on AIX by using Bash.

    acorn 5% grep -i CACHE configure.in
    AC_CACHE_SAVE
    acorn 6%

Doing it once is "excessively"?  Color me confused.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Top-level Makefile

[David Edelsohn]

>>>>> Phil Edwards writes:

Phil> On Thu, Nov 29, 2001 at 11:07:12AM -0500, David Edelsohn wrote:
>> This is because v3 saves and restores the state excessively which
>> some shells implement with temporary files.  I had a similar problem on
>> AIX.  I improved the situation on AIX by using Bash.

Phil> acorn 5% grep -i CACHE configure.in
Phil> AC_CACHE_SAVE
Phil> acorn 6%

Phil> Doing it once is "excessively"?  Color me confused.

	Because that is not "the state" to which I am refering.  We had a
long discussion about this back in March

http://gcc.gnu.org/ml/gcc/2001-03/msg00814.html

The problem is fragments like

cat >> confdefs.h <<\EOF
#define HAVE_FMODF 1
EOF

instead of using

echo "#define HAVE_FMODF 1" >> confdefs.h


The thread discussed solutions, but nothing ever was implemented.

David

Re: Top-level Makefile

[Phil Edwards]

On Thu, Nov 29, 2001 at 01:24:43PM -0500, David Edelsohn wrote:
> Because that is not "the state" to which I am refering.  We had a
> long discussion about this back in March

Oh, accumulating #define's.  Never would have thought of that as "state,"
personally.  :-)


> The thread discussed solutions, but nothing ever was implemented.

Yep.

Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Top-level Makefile

[Phil Edwards]

On Thu, Nov 29, 2001 at 01:24:43PM -0500, David Edelsohn wrote:
> Because that is not "the state" to which I am refering.  We had a
> long discussion about this back in March

Oh, accumulating #define's.  Never would have thought of that as "state,"
personally.  :-)


> The thread discussed solutions, but nothing ever was implemented.

Yep.

Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Top-level Makefile

[David Edelsohn]

>>>>> Phil Edwards writes:

Phil> On Thu, Nov 29, 2001 at 11:07:12AM -0500, David Edelsohn wrote:
>> This is because v3 saves and restores the state excessively which
>> some shells implement with temporary files.  I had a similar problem on
>> AIX.  I improved the situation on AIX by using Bash.

Phil> acorn 5% grep -i CACHE configure.in
Phil> AC_CACHE_SAVE
Phil> acorn 6%

Phil> Doing it once is "excessively"?  Color me confused.

	Because that is not "the state" to which I am refering.  We had a
long discussion about this back in March

http://gcc.gnu.org/ml/gcc/2001-03/msg00814.html

The problem is fragments like

cat >> confdefs.h <<\EOF
#define HAVE_FMODF 1
EOF

instead of using

echo "#define HAVE_FMODF 1" >> confdefs.h


The thread discussed solutions, but nothing ever was implemented.

David

Re: Top-level Makefile

[Phil Edwards]

On Thu, Nov 29, 2001 at 11:07:12AM -0500, David Edelsohn wrote:
> 	This is because v3 saves and restores the state excessively which
> some shells implement with temporary files.  I had a similar problem on
> AIX.  I improved the situation on AIX by using Bash.

    acorn 5% grep -i CACHE configure.in
    AC_CACHE_SAVE
    acorn 6%

Doing it once is "excessively"?  Color me confused.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Top-level Makefile

[David Edelsohn]

>>>>> Richard Kenner writes:

> Try some more efficient shell, such as bash or at least ksh.

Richard> Well, the shell script has #!/bin/sh" in the first line, so that's the
Richard> one that's going to be used.  It needs to work reasonably with that one.

	The shell is determined by target configure and substituted into
the script.

The problem I had with fastjar apparently has been fixed, but the major
problem is in configuring libstcv++v3.  Each of the following lines took 85
seconds, meaning the entire configure takes over an hour.  I'm on
alphaev56-dec-osfv4.0c.  The last time I reported this I was told it had been
fixed.  I see it has not ...

	This is because v3 saves and restores the state excessively which
some shells implement with temporary files.  I had a similar problem on
AIX.  I improved the situation on AIX by using Bash.

	I run Make with the following items in the incantation:

SHELL=/usr/gnu/bin/bash CONFIG_SHELL=/usr/gnu/bin/bash

and v3 configures in a human timescale again.

David

Re: Top-level Makefile

[Richard Kenner]

    make all does build with optimization, since it's assumed that this
    one is going to be installed.  make bootstrap builds stage1 without
    optimization.

OK, that makes sense.

    Try some more efficient shell, such as bash or at least ksh.

Well, the shell script has #!/bin/sh" in the first line, so that's the
one that's going to be used.  It needs to work reasonably with that one.

Top-level Makefile

[Richard Kenner]

I tried it and it seemed to build GCC with -O2 in the initial directory.
This seems wrong since you want to be able to debug that one easily.  It's
the ones built during bootstrap that should be -O2.

So it seems you need to do "make" in the gcc directory *first* and then
do the top-level make.  Is that correct?

BTW, my configure for libstdc++v3 is still running and it's been over an
hour and 45 minutes.

Re: Top-level Makefile

[Alexandre Oliva]

On Nov 29, 2001, kenner@vlsi1.ultra.nyu.edu (Richard Kenner) wrote:

> I tried it and it seemed to build GCC with -O2 in the initial directory.

make all does build with optimization, since it's assumed that this
one is going to be installed.  make bootstrap builds stage1 without
optimization.

> BTW, my configure for libstdc++v3 is still running and it's been over an
> hour and 45 minutes.

Try some more efficient shell, such as bash or at least ksh.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Top-level Makefile

[Alexandre Oliva]

On Nov 29, 2001, kenner@vlsi1.ultra.nyu.edu (Richard Kenner) wrote:

> I tried it and it seemed to build GCC with -O2 in the initial directory.

make all does build with optimization, since it's assumed that this
one is going to be installed.  make bootstrap builds stage1 without
optimization.

> BTW, my configure for libstdc++v3 is still running and it's been over an
> hour and 45 minutes.

Try some more efficient shell, such as bash or at least ksh.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Top-level Makefile

[Zack Weinberg]

On Thu, Nov 29, 2001 at 08:52:38AM -0500, Richard Kenner wrote:
> 
> BTW, my configure for libstdc++v3 is still running and it's been over an
> hour and 45 minutes.

We had some analysis awhile ago of this problem.  See 
http://gcc.gnu.org/ml/gcc/2001-03/msg00804.html

Could you please check the following things, to make sure it's the
same problem:

- Put "set -x" at the top of the configure script, then post the last
  thirty or so lines of the output once it gets stuck.

- Look in all the tmp directories your system has (/tmp, /usr/tmp,
  /var/tmp, etc) and see if there's a large number of scratch files
  created by the configure script.

zw

Re: Top-level Makefile

[Zack Weinberg]

On Thu, Nov 29, 2001 at 08:52:38AM -0500, Richard Kenner wrote:
> 
> BTW, my configure for libstdc++v3 is still running and it's been over an
> hour and 45 minutes.

We had some analysis awhile ago of this problem.  See 
http://gcc.gnu.org/ml/gcc/2001-03/msg00804.html

Could you please check the following things, to make sure it's the
same problem:

- Put "set -x" at the top of the configure script, then post the last
  thirty or so lines of the output once it gets stuck.

- Look in all the tmp directories your system has (/tmp, /usr/tmp,
  /var/tmp, etc) and see if there's a large number of scratch files
  created by the configure script.

zw

Re: Top-level Makefile

[Geoff Keating]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

> I tried it and it seemed to build GCC with -O2 in the initial directory.
> This seems wrong since you want to be able to debug that one easily.  It's
> the ones built during bootstrap that should be -O2.

A cross-compiler should be built with -O2.  I thought 'make bootstrap'
started with -O0.

> So it seems you need to do "make" in the gcc directory *first* and then
> do the top-level make.  Is that correct?

That doesn't sound right.  For natives, 'make bootstrap' should work
from the top level without special effort.

> BTW, my configure for libstdc++v3 is still running and it's been over an
> hour and 45 minutes.

Some non-linux OSs are very inefficient at running configure.  It's a
combination of the quality of the shell---you might try setting
CONFIG_SHELL to an installed recent bash---and the amount of caching
the filesystem does, which I think you're probably stuck with.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Re: Top-level Makefile

[Geoff Keating]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

> I tried it and it seemed to build GCC with -O2 in the initial directory.
> This seems wrong since you want to be able to debug that one easily.  It's
> the ones built during bootstrap that should be -O2.

A cross-compiler should be built with -O2.  I thought 'make bootstrap'
started with -O0.

> So it seems you need to do "make" in the gcc directory *first* and then
> do the top-level make.  Is that correct?

That doesn't sound right.  For natives, 'make bootstrap' should work
from the top level without special effort.

> BTW, my configure for libstdc++v3 is still running and it's been over an
> hour and 45 minutes.

Some non-linux OSs are very inefficient at running configure.  It's a
combination of the quality of the shell---you might try setting
CONFIG_SHELL to an installed recent bash---and the amount of caching
the filesystem does, which I think you're probably stuck with.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Top-level Makefile

[Richard Kenner]

I tried it and it seemed to build GCC with -O2 in the initial directory.
This seems wrong since you want to be able to debug that one easily.  It's
the ones built during bootstrap that should be -O2.

So it seems you need to do "make" in the gcc directory *first* and then
do the top-level make.  Is that correct?

BTW, my configure for libstdc++v3 is still running and it's been over an
hour and 45 minutes.