From xemacs-m  Mon Mar 17 05:07:56 1997
Received: from altair.xemacs.org (steve@xemacs.miranova.com [206.190.83.19])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id FAA12333
	for <xemacs-beta@xemacs.org>; Mon, 17 Mar 1997 05:07:56 -0600 (CST)
Received: (from steve@localhost)
	by altair.xemacs.org (8.8.5/8.8.5) id DAA17955;
	Mon, 17 Mar 1997 03:19:50 -0800
Mail-Copies-To: never
To: xemacs-beta@xemacs.org
Subject: Re: [ 19.15-b99 and 20.1-b7] build FAILURE on Solaris-2.5/X11R6.3/cc-4.0
References: <m2vi6si7nw.fsf@altair.xemacs.org> <vkhgibh8ud.fsf@cdc.noaa.gov>
X-Url: http://www.miranova.com/%7Esteve/
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
X-Attribution: sb
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Mark Borges's message of 16 Mar 1997 13:37:14 -0700
Mime-Version: 1.0 (generated by tm-edit 7.105)
Content-Type: text/plain; charset=US-ASCII
Date: 17 Mar 1997 03:19:43 -0800
Message-ID: <m2afo222b4.fsf@altair.xemacs.org>
Lines: 43
X-Mailer: Gnus v5.4.26/XEmacs 20.1(beta8)

Mark Borges writes:

> This must be sparcworks related...

Yup.  Why, oh why can't sparcworks behave like the rest of XEmacs???

Temporary workaround is to compile without Sparcworks or whatever
specifically forces comint.elc to be dumped with XEmacs.  Andy Piper:
this applies to your problem too.

> Both 20.1-b7 and 19.15-b99 fail to build, and bomb out with this
> backtrace (I guess it eventually quit trying to build as /tmp wasn't
> full, but that brings up a question -- with the new dynamic puresize
> scheme, how long will it try to dump?). I haven't changed any
> configure flags in a month or so, but if you want them just let me know.

That's a known problem.  There needs to be a cut off in doing builds
in case of total disaster.  The only person who's supposed to see
total disaster when building is me.  Fix in the next betas (which will 
probably come sooner rather than next weekend :-( ).

> Anyway, here's the backtrace lossage from the build:

> Loading sunpro-init...
> Loading eos/sun-eos-load...*** Error in XEmacs initialization
> (error "Attempt to declare a face during dump")
 ...
>   load("comint" nil t nil)
>   # (unwind-protect ...)
>   require(comint)

Comint.el now has a (defface ...) in it.  Apparently we cannot dump
anything which calls defface at the outer level.  It looks like a
custom limitation.  I agree with the comment `This should be allowed,
somehow'.  Suggestions are welcome.  Per, did you put that in to avoid 
a certain XEmacs coredump?

I don't know what the right answer is.  It certainly isn't to 
make some weird kludge to comint.el to avoid the defface at dump time
but not runtime, I think.  This sort of thing should just work.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.

