R> does latin-unity-tables.el need to be there if it gets rebuilt R> everytime ?? Stephen> Yes, because building it depends on Mule-UCS, which I'd rather not Stephen> impose on people who don't need it. I've figured out how to check for Stephen> this, and a rather evil fix is in CVS. Ville, Steve, would you guys Stephen> take a look at my evil experiment in conditional REQUIRES? (patch is Stephen> in <87vg3ihmwk.fsf(a)tleepslib.sk.tsukuba.ac.jp&gt; on xemacs-patches) R> i ask because latin-unity is breaking the pkg-build script R> because of this required user interaction Stephen> Fix for this committed to CVS. just tried a gmake for latin-unity (again) now i get this Loading reldata/uviscii... # bind ( stack-trace-on-signal debug-on-signal stack-trace-on-error debug-on-error) signal(void-variable (progn)) # bind (data error-symbol) signal-error(void-variable (progn)) # bind (error-data) normal-top-level() # (condition-case ... . error) # (catch top-level ...) Symbol's value as variable is void: progn xemacs exiting . gmake: *** [latin-unity-tables.el] Error 255 any ideas on this ?? -- XEmacs Advocate | Do not try the patience of Wizards, FreeBSD Devote | for they are subtle and quick to anger. Perl Hacker | - Elric (Technomage) , Babylon 5. Apache God | <mailto:rendhalver at xemacs.org> <GnuPG KeyID: AE51D190>

R> just tried a gmake for latin-unity (again) R> now i get this R> Loading reldata/uviscii... # bind ( R> stack-trace-on-signal debug-on-signal stack-trace-on-error debug-on-error) R> signal(void-variable (progn)) Stephen> Maybe you need to rebuild mule-ucs? You shouldn't be loading that Stephen> file, it should be preloaded into un-define.elc. um ok i rebuilt mule-ucs and now latin-unity builds thanks stephen got any more fixes before i do another pre-release ?? -- XEmacs Advocate | Do not try the patience of Wizards, FreeBSD Devote | for they are subtle and quick to anger. Perl Hacker | - Elric (Technomage) , Babylon 5. Apache God | <mailto:rendhalver at xemacs.org> <GnuPG KeyID: AE51D190>

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: Hi! FWIW, I can't reproduce this on my FreeBSD 4.7 machine. Do you perform any steps to get it crashing? norbert.

viteno> FWIW, I can't reproduce this on my FreeBSD 4.7 machine. viteno> Do you perform any steps to get it crashing? Stephen> Build without --pdump. is it time to make --pdump a standard build arg ?? -- XEmacs Advocate | Do not try the patience of Wizards, FreeBSD Devote | for they are subtle and quick to anger. Perl Hacker | - Elric (Technomage) , Babylon 5. Apache God | <mailto:rendhalver at xemacs.org> <GnuPG KeyID: AE51D190>

viteno> Do you perform any steps to get it crashing? Stephen> Build without --pdump. R> is it time to make --pdump a standard build arg ?? Possibly ... but not until this crash is understood. viteno> Hmm, I did viteno> ./configure --with-mule viteno> make viteno> src/xemacs --vanilla viteno> and everything was fine. Ah, but of course! You're not on Linux! At this point I'm convinced it's my own environment. 21.4.10rc3, 21.4.10rc, 21.4.10rc1, and 21.4.9 all crash in the same way under the conditions of my build script, when none of them did when I released them. All of those have been built by several people on Linux with and without --pdump. I suspect it's related to the recent mysterious Red Hat 8 crashes. I'm definitely tempted to finger glibc 2.3.1, as I was able to build on a similar machine with glibc 2.2.5, then the build failed when I upgraded (and of course I can't test going in the opposite direction because the dependencies go the wrong way). OK, I guess with that much confirmation I can release. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py