David, Here's what Martin Buchholz suggests; can you see if you can reproduce the problem in a fresh xemacs-21.1.8? Thanks, vin shelton X-From-Line: martin(a)xemacs.org Thu Dec 14 00:28:56 2000 Return-Path: <martin(a)xemacs.org&gt; Delivered-To: acs(a)localhost.rcn.com Received: from localhost (localhost.localdomain [127.0.0.1]) by zion.rcn.com (Postfix) with ESMTP id 9E594BB54 for <acs＠localhost>; Thu, 14 Dec 2000 00:28:56 -0500 (EST) Received: from alumni.princeton.edu [204.153.50.12] by localhost with POP3 (fetchmail-5.4.1) for acs＠localhost (single-drop); Thu, 14 Dec 2000 00:28:56 -0500 (EST) Received: from gwyn.tux.org (ident-user(a)gwyn.tux.org [207.96.122.8]) by alumni.Princeton.EDU (8.9.1/8.9.1) with ESMTP id AAA19105 for <acs(a)alumni.princeton.edu>; Thu, 14 Dec 2000 00:26:15 -0500 (EST) Received: from tsukuba.m17n.org (tsukuba.m17n.org [192.47.44.130]) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id AAA16342; Thu, 14 Dec 2000 00:26:06 -0500 Received: from fs.m17n.org (root(a)fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.9.3/3.7W-19991231100513) with ESMTP id OAA26368; Thu, 14 Dec 2000 14:26:04 +0900 (JST) (envelope-from martin(a)m17n.org) Received: from mule.m17n.org (martin(a)mule.m17n.org [192.47.44.3]) by fs.m17n.org (8.9.3/3.7W-19990906215257) with ESMTP id OAA21791; Thu, 14 Dec 2000 14:26:03 +0900 (JST) Received: (from martin＠localhost) by mule.m17n.org (8.9.2/3.7W-19990512194415) id OAA29247; Thu, 14 Dec 2000 14:26:02 +0900 (JST) Message-ID: <14904.23018.156932.609507(a)mule.m17n.org&gt; Date: Thu, 14 Dec 2000 14:26:02 +0900 (JST) From: Martin Buchholz <martin(a)xemacs.org&gt; Sender: martin(a)xemacs.org To: Vin Shelton <acs(a)xemacs.org&gt; Cc: xemacs-beta(a)xemacs.org Subject: Re: [comp.emacs.xemacs] Package incompatibility In-Reply-To: <m2ae9z3a0c.fsf(a)zion.rcn.com&gt; References: <m2ae9z3a0c.fsf(a)zion.rcn.com&gt; X-Mailer: VM 6.71 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-UIDL: e3307cc1550cb225230c7d597169ad1e Lines: 43 Xref: zion.rcn.com XEmacs:20996 Vin> As the maintainer of the current stable release, I must concur. Steve Vin> Youngs (I know you're out of touch at the moment, perhaps you'll Vin> comment when you get back) please build with the latest stable Vin> release, in this case 21.1. It is a very serious bug if XEmacs 21.2-compiled code can't run on 21.1. I can't reproduce it. Vin> It is now impossible to use M-x calendar. The exact error message I Vin> get when doing M-x calendar is: Vin> invalid lazy-loaded byte code: k«„Ã Vin> The file calendar.elc is generated by XEmacs 21.2 (beta36). It appears Vin> that the output of this byte compiler is not entirely compatible with Vin> XEmacs 21.1.8. I think that's unlikely. What happens if you start up a NEW 21.1.8 xemacs process, and try M-x calendar? I believe there is a bug here, but it is that lazy-loading of bytecode and docstrings does not check the timestamps of updated files, and would happen with any xemacs version. Workaround: shut down your running xemacs and start up a new one. Vin> For pacakges to work, this sort of thing *has* to be avoided. Either Vin> by using separate package directories for separate versions of XEmacs Vin> or by recompiling packages as they are retreived if they are not Vin> precompiled with a compatible version of XEmacs. I agree completely.