* Re: Top-level Makefile
@ 2001-11-22 20:31 Richard Kenner
2001-11-23 2:01 ` David Edelsohn
2001-11-30 3:43 ` Richard Kenner
0 siblings, 2 replies; 40+ messages in thread
From: Richard Kenner @ 2001-11-22 20:31 UTC (permalink / raw)
To: aoliva; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
2001-11-22 20:31 Top-level Makefile Richard Kenner
@ 2001-11-23 2:01 ` David Edelsohn
2001-11-30 8:17 ` David Edelsohn
2001-11-30 3:43 ` Richard Kenner
1 sibling, 1 reply; 40+ messages in thread
From: David Edelsohn @ 2001-11-23 2:01 UTC (permalink / raw)
To: Richard Kenner; +Cc: aoliva, gcc
>>>>> 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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
2001-11-23 2:01 ` David Edelsohn
@ 2001-11-30 8:17 ` David Edelsohn
0 siblings, 0 replies; 40+ messages in thread
From: David Edelsohn @ 2001-11-30 8:17 UTC (permalink / raw)
To: Richard Kenner; +Cc: aoliva, gcc
>>>>> 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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
2001-11-22 20:31 Top-level Makefile Richard Kenner
2001-11-23 2:01 ` David Edelsohn
@ 2001-11-30 3:43 ` Richard Kenner
1 sibling, 0 replies; 40+ messages in thread
From: Richard Kenner @ 2001-11-30 3:43 UTC (permalink / raw)
To: aoliva; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
@ 2001-11-24 18:04 Richard Kenner
2001-11-24 19:19 ` Zack Weinberg
2001-11-30 19:01 ` Richard Kenner
0 siblings, 2 replies; 40+ messages in thread
From: Richard Kenner @ 2001-11-24 18:04 UTC (permalink / raw)
To: zack; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
2001-11-24 18:04 Richard Kenner
@ 2001-11-24 19:19 ` Zack Weinberg
2001-11-30 20:16 ` Zack Weinberg
2001-11-30 19:01 ` Richard Kenner
1 sibling, 1 reply; 40+ messages in thread
From: Zack Weinberg @ 2001-11-24 19:19 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
2001-11-24 19:19 ` Zack Weinberg
@ 2001-11-30 20:16 ` Zack Weinberg
0 siblings, 0 replies; 40+ messages in thread
From: Zack Weinberg @ 2001-11-30 20:16 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
2001-11-24 18:04 Richard Kenner
2001-11-24 19:19 ` Zack Weinberg
@ 2001-11-30 19:01 ` Richard Kenner
1 sibling, 0 replies; 40+ messages in thread
From: Richard Kenner @ 2001-11-30 19:01 UTC (permalink / raw)
To: zack; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
@ 2001-11-24 14:25 Richard Kenner
2001-11-24 15:02 ` Zack Weinberg
` (3 more replies)
0 siblings, 4 replies; 40+ messages in thread
From: Richard Kenner @ 2001-11-24 14:25 UTC (permalink / raw)
To: dje; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
2001-11-24 14:25 Richard Kenner
@ 2001-11-24 15:02 ` Zack Weinberg
2001-11-30 18:14 ` Zack Weinberg
2001-11-24 16:57 ` Bryce McKinlay
` (2 subsequent siblings)
3 siblings, 1 reply; 40+ messages in thread
From: Zack Weinberg @ 2001-11-24 15:02 UTC (permalink / raw)
To: Richard Kenner; +Cc: dje, gcc
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
2001-11-24 15:02 ` Zack Weinberg
@ 2001-11-30 18:14 ` Zack Weinberg
0 siblings, 0 replies; 40+ messages in thread
From: Zack Weinberg @ 2001-11-30 18:14 UTC (permalink / raw)
To: Richard Kenner; +Cc: dje, gcc
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
2001-11-24 14:25 Richard Kenner
2001-11-24 15:02 ` Zack Weinberg
@ 2001-11-24 16:57 ` Bryce McKinlay
2001-11-30 18:32 ` Bryce McKinlay
2001-11-24 18:09 ` David Edelsohn
2001-11-30 17:44 ` Richard Kenner
3 siblings, 1 reply; 40+ messages in thread
From: Bryce McKinlay @ 2001-11-24 16:57 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
2001-11-24 16:57 ` Bryce McKinlay
@ 2001-11-30 18:32 ` Bryce McKinlay
0 siblings, 0 replies; 40+ messages in thread
From: Bryce McKinlay @ 2001-11-30 18:32 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
2001-11-24 14:25 Richard Kenner
2001-11-24 15:02 ` Zack Weinberg
2001-11-24 16:57 ` Bryce McKinlay
@ 2001-11-24 18:09 ` David Edelsohn
2001-11-30 19:33 ` David Edelsohn
2001-11-30 17:44 ` Richard Kenner
3 siblings, 1 reply; 40+ messages in thread
From: David Edelsohn @ 2001-11-24 18:09 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc
>>>>> 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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
2001-11-24 18:09 ` David Edelsohn
@ 2001-11-30 19:33 ` David Edelsohn
0 siblings, 0 replies; 40+ messages in thread
From: David Edelsohn @ 2001-11-30 19:33 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc
>>>>> 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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
2001-11-24 14:25 Richard Kenner
` (2 preceding siblings ...)
2001-11-24 18:09 ` David Edelsohn
@ 2001-11-30 17:44 ` Richard Kenner
3 siblings, 0 replies; 40+ messages in thread
From: Richard Kenner @ 2001-11-30 17:44 UTC (permalink / raw)
To: dje; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
@ 2001-11-22 20:28 Richard Kenner
2001-11-24 16:41 ` Zack Weinberg
2001-11-30 3:05 ` Richard Kenner
0 siblings, 2 replies; 40+ messages in thread
From: Richard Kenner @ 2001-11-22 20:28 UTC (permalink / raw)
To: zack; +Cc: gcc
- 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.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
2001-11-22 20:28 Richard Kenner
@ 2001-11-24 16:41 ` Zack Weinberg
2001-11-30 18:17 ` Zack Weinberg
2001-11-30 3:05 ` Richard Kenner
1 sibling, 1 reply; 40+ messages in thread
From: Zack Weinberg @ 2001-11-24 16:41 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
2001-11-24 16:41 ` Zack Weinberg
@ 2001-11-30 18:17 ` Zack Weinberg
0 siblings, 0 replies; 40+ messages in thread
From: Zack Weinberg @ 2001-11-30 18:17 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
2001-11-22 20:28 Richard Kenner
2001-11-24 16:41 ` Zack Weinberg
@ 2001-11-30 3:05 ` Richard Kenner
1 sibling, 0 replies; 40+ messages in thread
From: Richard Kenner @ 2001-11-30 3:05 UTC (permalink / raw)
To: zack; +Cc: gcc
- 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.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
@ 2001-11-21 14:38 Richard Kenner
2001-11-21 15:14 ` Alexandre Oliva
` (2 more replies)
0 siblings, 3 replies; 40+ messages in thread
From: Richard Kenner @ 2001-11-21 14:38 UTC (permalink / raw)
To: aoliva; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
2001-11-21 14:38 Richard Kenner
@ 2001-11-21 15:14 ` Alexandre Oliva
2001-11-29 8:01 ` Alexandre Oliva
2001-11-21 15:16 ` David Edelsohn
2001-11-29 6:50 ` Richard Kenner
2 siblings, 1 reply; 40+ messages in thread
From: Alexandre Oliva @ 2001-11-21 15:14 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
2001-11-21 15:14 ` Alexandre Oliva
@ 2001-11-29 8:01 ` Alexandre Oliva
0 siblings, 0 replies; 40+ messages in thread
From: Alexandre Oliva @ 2001-11-29 8:01 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
2001-11-21 14:38 Richard Kenner
2001-11-21 15:14 ` Alexandre Oliva
@ 2001-11-21 15:16 ` David Edelsohn
2001-11-21 15:52 ` Phil Edwards
2001-11-29 8:09 ` David Edelsohn
2001-11-29 6:50 ` Richard Kenner
2 siblings, 2 replies; 40+ messages in thread
From: David Edelsohn @ 2001-11-21 15:16 UTC (permalink / raw)
To: Richard Kenner; +Cc: aoliva, gcc
>>>>> 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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
2001-11-21 15:16 ` David Edelsohn
@ 2001-11-21 15:52 ` Phil Edwards
2001-11-21 19:20 ` David Edelsohn
2001-11-29 8:55 ` Phil Edwards
2001-11-29 8:09 ` David Edelsohn
1 sibling, 2 replies; 40+ messages in thread
From: Phil Edwards @ 2001-11-21 15:52 UTC (permalink / raw)
To: David Edelsohn; +Cc: Richard Kenner, gcc
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
2001-11-21 15:52 ` Phil Edwards
@ 2001-11-21 19:20 ` David Edelsohn
2001-11-21 22:04 ` Phil Edwards
2001-11-29 10:27 ` David Edelsohn
2001-11-29 8:55 ` Phil Edwards
1 sibling, 2 replies; 40+ messages in thread
From: David Edelsohn @ 2001-11-21 19:20 UTC (permalink / raw)
To: Phil Edwards; +Cc: Richard Kenner, gcc
>>>>> 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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
2001-11-21 19:20 ` David Edelsohn
@ 2001-11-21 22:04 ` Phil Edwards
2001-11-29 11:04 ` Phil Edwards
2001-11-29 10:27 ` David Edelsohn
1 sibling, 1 reply; 40+ messages in thread
From: Phil Edwards @ 2001-11-21 22:04 UTC (permalink / raw)
To: David Edelsohn; +Cc: Richard Kenner, gcc
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
2001-11-21 22:04 ` Phil Edwards
@ 2001-11-29 11:04 ` Phil Edwards
0 siblings, 0 replies; 40+ messages in thread
From: Phil Edwards @ 2001-11-29 11:04 UTC (permalink / raw)
To: David Edelsohn; +Cc: Richard Kenner, gcc
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
2001-11-21 19:20 ` David Edelsohn
2001-11-21 22:04 ` Phil Edwards
@ 2001-11-29 10:27 ` David Edelsohn
1 sibling, 0 replies; 40+ messages in thread
From: David Edelsohn @ 2001-11-29 10:27 UTC (permalink / raw)
To: Phil Edwards; +Cc: Richard Kenner, gcc
>>>>> 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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
2001-11-21 15:52 ` Phil Edwards
2001-11-21 19:20 ` David Edelsohn
@ 2001-11-29 8:55 ` Phil Edwards
1 sibling, 0 replies; 40+ messages in thread
From: Phil Edwards @ 2001-11-29 8:55 UTC (permalink / raw)
To: David Edelsohn; +Cc: Richard Kenner, gcc
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
2001-11-21 15:16 ` David Edelsohn
2001-11-21 15:52 ` Phil Edwards
@ 2001-11-29 8:09 ` David Edelsohn
1 sibling, 0 replies; 40+ messages in thread
From: David Edelsohn @ 2001-11-29 8:09 UTC (permalink / raw)
To: Richard Kenner; +Cc: aoliva, gcc
>>>>> 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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
2001-11-21 14:38 Richard Kenner
2001-11-21 15:14 ` Alexandre Oliva
2001-11-21 15:16 ` David Edelsohn
@ 2001-11-29 6:50 ` Richard Kenner
2 siblings, 0 replies; 40+ messages in thread
From: Richard Kenner @ 2001-11-29 6:50 UTC (permalink / raw)
To: aoliva; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Top-level Makefile
@ 2001-11-21 14:00 Richard Kenner
2001-11-21 14:27 ` Alexandre Oliva
` (3 more replies)
0 siblings, 4 replies; 40+ messages in thread
From: Richard Kenner @ 2001-11-21 14:00 UTC (permalink / raw)
To: gcc
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.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
2001-11-21 14:00 Richard Kenner
@ 2001-11-21 14:27 ` Alexandre Oliva
2001-11-29 6:46 ` Alexandre Oliva
2001-11-21 15:59 ` Zack Weinberg
` (2 subsequent siblings)
3 siblings, 1 reply; 40+ messages in thread
From: Alexandre Oliva @ 2001-11-21 14:27 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
2001-11-21 14:27 ` Alexandre Oliva
@ 2001-11-29 6:46 ` Alexandre Oliva
0 siblings, 0 replies; 40+ messages in thread
From: Alexandre Oliva @ 2001-11-29 6:46 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
2001-11-21 14:00 Richard Kenner
2001-11-21 14:27 ` Alexandre Oliva
@ 2001-11-21 15:59 ` Zack Weinberg
2001-11-29 9:11 ` Zack Weinberg
2001-11-22 13:53 ` Geoff Keating
2001-11-29 5:58 ` Richard Kenner
3 siblings, 1 reply; 40+ messages in thread
From: Zack Weinberg @ 2001-11-21 15:59 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
2001-11-21 15:59 ` Zack Weinberg
@ 2001-11-29 9:11 ` Zack Weinberg
0 siblings, 0 replies; 40+ messages in thread
From: Zack Weinberg @ 2001-11-29 9:11 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
2001-11-21 14:00 Richard Kenner
2001-11-21 14:27 ` Alexandre Oliva
2001-11-21 15:59 ` Zack Weinberg
@ 2001-11-22 13:53 ` Geoff Keating
2001-11-30 0:08 ` Geoff Keating
2001-11-29 5:58 ` Richard Kenner
3 siblings, 1 reply; 40+ messages in thread
From: Geoff Keating @ 2001-11-22 13:53 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc
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>
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Top-level Makefile
2001-11-22 13:53 ` Geoff Keating
@ 2001-11-30 0:08 ` Geoff Keating
0 siblings, 0 replies; 40+ messages in thread
From: Geoff Keating @ 2001-11-30 0:08 UTC (permalink / raw)
To: Richard Kenner; +Cc: gcc
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>
^ permalink raw reply [flat|nested] 40+ messages in thread
* Top-level Makefile
2001-11-21 14:00 Richard Kenner
` (2 preceding siblings ...)
2001-11-22 13:53 ` Geoff Keating
@ 2001-11-29 5:58 ` Richard Kenner
3 siblings, 0 replies; 40+ messages in thread
From: Richard Kenner @ 2001-11-29 5:58 UTC (permalink / raw)
To: gcc
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.
^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~2001-12-01 4:16 UTC | newest]
Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-11-22 20:31 Top-level Makefile Richard Kenner
2001-11-23 2:01 ` David Edelsohn
2001-11-30 8:17 ` David Edelsohn
2001-11-30 3:43 ` Richard Kenner
-- strict thread matches above, loose matches on Subject: below --
2001-11-24 18:04 Richard Kenner
2001-11-24 19:19 ` Zack Weinberg
2001-11-30 20:16 ` Zack Weinberg
2001-11-30 19:01 ` Richard Kenner
2001-11-24 14:25 Richard Kenner
2001-11-24 15:02 ` Zack Weinberg
2001-11-30 18:14 ` Zack Weinberg
2001-11-24 16:57 ` Bryce McKinlay
2001-11-30 18:32 ` Bryce McKinlay
2001-11-24 18:09 ` David Edelsohn
2001-11-30 19:33 ` David Edelsohn
2001-11-30 17:44 ` Richard Kenner
2001-11-22 20:28 Richard Kenner
2001-11-24 16:41 ` Zack Weinberg
2001-11-30 18:17 ` Zack Weinberg
2001-11-30 3:05 ` Richard Kenner
2001-11-21 14:38 Richard Kenner
2001-11-21 15:14 ` Alexandre Oliva
2001-11-29 8:01 ` Alexandre Oliva
2001-11-21 15:16 ` David Edelsohn
2001-11-21 15:52 ` Phil Edwards
2001-11-21 19:20 ` David Edelsohn
2001-11-21 22:04 ` Phil Edwards
2001-11-29 11:04 ` Phil Edwards
2001-11-29 10:27 ` David Edelsohn
2001-11-29 8:55 ` Phil Edwards
2001-11-29 8:09 ` David Edelsohn
2001-11-29 6:50 ` Richard Kenner
2001-11-21 14:00 Richard Kenner
2001-11-21 14:27 ` Alexandre Oliva
2001-11-29 6:46 ` Alexandre Oliva
2001-11-21 15:59 ` Zack Weinberg
2001-11-29 9:11 ` Zack Weinberg
2001-11-22 13:53 ` Geoff Keating
2001-11-30 0:08 ` Geoff Keating
2001-11-29 5:58 ` Richard Kenner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).