d> I just tried to compile package xemacs-21.5.24-2 with the GNU C d> compiler. I'll check this in our sources, but there is no such version as 21.5.24-2. I suggest you talk to your vendor about their package. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

Mike> It is in the original sources already. Of course. What I meant was that most vendors are very careful about which betas they choose to base a distribution on, and they might want to apply the patch to 21.5.24 rather than release an update based on current CVS (you may have noticed that Marcus is planning to continue destabilizing the GC code ;-). Mike> The variable "xlfd" looks superfluous to me in that Mike> function. It is. I suspect it was probably intended to be xlfd[1024] or something like that. I've got another patch that uses NEW_LISP_STRING_TO_EXTERNAL instead, which is much easier to read since it returns the Extbyte*, so there's no waffle about whether you need to allocate storage. I suspect that the GCC issue that led to use of return-via-argument in the LISP_STRING_TO_EXTERNAL macro probably has been solved since GCC 2.90 or so, and we should probably start using the NEW_* versions (or maybe EiStrings) anyway. Your patch accomplishes the same thing, of course. Thanks for the confirmation that this is the right way to go! -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

Fri, 17 Feb 2006 16:27:07 +0100, Mike FABIAN wrote: It's a normal, it is a debug info. See in xemacs-patches Marcus Crestani patch, removes this "flood". -- Regards, Andrey.