Re: libstdc++ configure time

[Richard Henderson <rth at redhat dot 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

real     1:58.4
user       43.6
sys        38.1

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
EOF

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

instead.

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.


r~