This is the mail archive of the
mailing list for the GCC project.
Re: libstdc++ configure time
- To: gcc at gcc dot gnu dot org
- Subject: Re: libstdc++ configure time
- From: Richard Henderson <rth at redhat dot com>
- Date: Sun, 18 Mar 2001 12:41:40 -0800
- Cc: Alexandre Oliva <aoliva at redhat dot com>
- References: <20010318015411.A28945@redhat.com>
On Sun, Mar 18, 2001 at 01:54:11AM -0800, Richard Henderson wrote:
> I know this has been discussed off and on before, but has anyone figured
> out why libstdc++ configures so amazingly slowly on non-linux?
Data: It is some form of extreme /bin/sh losage.
If I set SHELL and CONFIG_SHELL to bash, then
"time make configure-target-libstdc++-v3" takes
Yep, just under two minutes for the whole thing.
So I started poking around to see what in the world /bin/sh is doing
all that time. The answer appears to be linking and unlinking
bill-yuns and bill-yuns of tiny little files in /tmp:
stat("/tmp/sh26244675", 0xEFFFEC68) Err#2 ENOENT
link("/tmp/sh26244370", "/tmp/sh26244675") = 0
stat("/tmp/sh26244676", 0xEFFFEC68) Err#2 ENOENT
link("/tmp/sh26244369", "/tmp/sh26244676") = 0
stat("/tmp/sh26244677", 0xEFFFEC68) Err#2 ENOENT
link("/tmp/sh26244368", "/tmp/sh26244677") = 0
And so it goes for the next thousand lines or so. If anyone wants
to look at lots of boring, repetitive truss output, ask.
Now, the interesting part is the contents of these files:
$ ls -l /tmp/sh* | head -5
-rw-rw-r-- 2 rth cygnus 21 Mar 18 11:46 /tmp/sh26244100
-rw-rw-r-- 2 rth cygnus 22 Mar 18 11:46 /tmp/sh26244101
-rw-rw-r-- 2 rth cygnus 21 Mar 18 11:46 /tmp/sh26244102
-rw-rw-r-- 2 rth cygnus 22 Mar 18 11:46 /tmp/sh26244103
-rw-rw-r-- 2 rth cygnus 21 Mar 18 11:46 /tmp/sh26244104
$ cat /tmp/sh26244100
#define HAVE_FMODF 1
Pop quiz, autoconf maintainers, where does this come from? Hint:
cat >> confdefs.h <<\EOF
#define HAVE_FMODF 1
I count 485 ocurrences of ^EOF in this configure script. Given
that it would appear that Solaris /bin/sh wants to make a hard link
to each of these 485 input fragments whenever it forks a subshell,
it would appear to be fantastically cheaper to use
echo "#define HAVE_FMODF 1" >> confdefs.h
Any bright ideas on how to determine (or massage) the fragments
of configure.in such that they are (appropriately) safe from shell
expansion? It appears that virtually everything in our scripts
would work if s/\([\"]\)/\\\1/g was passed over the input.