This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: libstdc++ configure time

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

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 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]