[Bug: 21.5-b28] Hang in building custom-loads at descr-text.el

[Stephen J. Turnbull]

Aidan Kehoe writes:
 > 
 >  Ar an t-aonú lá is triochad de mí na Nollaig, scríobh Stephen J. Turnbull: 
 > 
 >  > Aidan,
 >  > 
 >  > This bug's for you!
 >  > 
 >  > This is just your everyday ordinary configure ...; make beta, except
 >  > that it didn't finish.  The C backtrace is uninformative, except that
 >  > obviously XEmacs is waiting for subprocess output that never comes.
 >  > The Lisp backtrace fingers an ";; XEmacs change" in descr-text.el
 >  > pretty conclusively.
 >  > 
 >  > I don't see anything wrong with the code, so it may be a bug in our
 >  > process code.  But if you don't see a fix, I think we need to make
 >  > that initialization stuff an explicit user request.
 > 
 > I don't see the problem when I build with your configure line, and given
 > that, I don't anticipate finding a fix myself.

If you don't have real fix (it's not your responsibility, of course),
the build is still repeatably broken for me in a pristine checkout,
and we need to work around it until we know that it won't happen to
others.  Move that code out of the defcustom, please.

 > Do you have perl installed? 

Yes.

 > Does perl -V:installprivlib give anything sensible from the shell?

Yes.  It says "installprivlib='/opt/local/lib/perl5/5.8.8';".

 > Was it actually the initialisation of
 > describe-char-unicodedata-file that hanged?

Sure looks that way to me from the Lisp backtrace.  What else could it
be?

 > descr-text.el is not dumped, this code won't be executed for most users most
 > of the time. 

True.  Because "most users" don't build XEmacs.

However, every time XEmacs is built and the custom-loads file is
rebuilt, it gets executed.  Leaving the build broken is not
acceptable, even if this case is going to be rare.