Yes, this patch solves the problem.

Thank you very much!

New openSUSE packages including that patch 
are submitted to the M17N project in the openSUSE build
service and will soon be available here:

http://download.opensuse.org/repositories/M17N/


in the open

A recursive grep of the lisp in 21.5 and the package tree
shows none in code, and a very ancient (refers to the *junet*
coding system) recipe in the Mule-FAQ (in mule-base).  Thus
latin-unity's hook is the only one in general use AFAICS.

Mike, could you try the attached patch (bytecomp.diff)?

OK, I guess what needs to happen is that when the coding
system is determined in `byte-compile-insert-header', rather
than setting buffer-file-coding-system, this needs to be
forced in the call to `write-region' in `byte-compile-file'.

Maybe better, wrap the call to `write-region' in

(let ((write-region-pre-hook nil)) ...)

This should be safe as I can't imagine a prehook that should
be allowed to run before writing a .elc.

I can easily reproduce it like this:

    xemacs -vanilla &
    M-x byte-compile-file RET
    ~/.xemacs/init.el RET

compiled file init.elc is OK now. Continue:

    M-x latin-unity-install RET
    M-x byte-compile-file RET
    ~/.xemacs/init.el RET

compiled file init.elc is broken now.

Sorry for claiming it happens only on 64bit. This was wrong and
misleading. On the 32bit system I had a slightly older
openSUSE xemacs packages with slightly different system startup
files.

It doesn’t really depend on the locale either, the problem
seems to be caused by latin-unity.

The openSUSE site-start.el uses latin-unity, it contains:

    (if (fboundp 'latin-unity-install) (latin-unity-install))

but it does not do this in POSIX locale because this would happen:

     LANG=POSIX xemacs
     M-x latin-unity-install RET
     C-x C-f new-file RET
     type some text
     C-x C-s

     and then one gets the message:

	Choose a coding system to save buffer new-file.
	All preapproved coding systems (buffer-default==iso-latin-1
preferred==iso-latin-1)
	fail to appropriately encode some of the characters present
in the buffer.

	Please pick a coding system.  The following are recommended
because they can
	encode any character in the buffer:

    utf-8 iso-2022-7 ctext escape-quoted

and this would certainly confuse people who only want to use
POSIX.

In an UTF-8 locale, the preferred coding system is already
utf-8 and
therefore this confusing message doesn’t appear.

LANG=C xemacs  -batch -f batch-byte-compile init.el

also works, without vanilla!

LANG=en_US.UTF-8 xemacs  -batch -f batch-byte-compile init.el

does *not* work.

Adding the option "-vanilla" while byte compiling

    xemacs -vanilla -batch -f batch-byte-compile init.el

makes it work on 64bit as well.

init.elc compiled on a 32bit system.

The problem seems to occur only on 64 bit systems!

When I byte compile the file like this

   xemacs -batch -f batch-byte-compile init.el

and do this once on a 32bit system and once on a 64bit system
using
the same xemacs versions (i.e. build from the same sources
with the
same patches and options), the byte compiled files are different.

The file compiled on the 32bit system works (even if copied
to a 64bit system), the file compiled on the 64bit system does not
work.

Easier than downloading the source rpm and unpacking it with
rpm2cpio
to get the patches might be to look at the xemacs page in the
openSUSE
build service:

https://build.opensuse.org/package/show?package=xemacs&project=M17N

An openSUSE account is needed to access this page but creating
an openSUSE account is easy to do on www.opensuse.org.

(On http://en.opensuse.org/Welcome_to_openSUSE.org at the top
right
corner is the "Create an account" button).

On the xemacs project page in the openSUSE build service one
can easily browse the patches.

The SuSE package of xemacs has some patches applied.
But I believe none of them has anything to do with the 
byte code compiler.

The source rpm, which contains all patches, is available here.

http://download.opensuse.org/repositories/M17N/SUSE_Factory/src/

The byte compiled simple init.el file.

M-x describe-installation RET

The file ~/.xemacs/custom.el which I used in my test init.el in
msg831 did not exist. I forgot to mention that. 

I made the test init.el even simpler now:

lmfabian@magellan:~/.xemacs> cat init.el
(setq mike-test "hello")

lmfabian@magellan:~/.xemacs>

Still the same problem:


(1) (initialization/error) An error has occurred while loading
/home/lmfabian/.xemacs/init.elc:

Invalid byte code: reference 3 to constants array out of range
0, 2

Backtrace follows:

  byte-code("..." [mike-test "hello" nil] 1)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  load-internal("/home/lmfabian/.xemacs/init.elc" t t t binary)
  # bind (handler path nosuffix nomessage noerror filename)
  load("/home/lmfabian/.xemacs/init.elc" t t t)
  load-user-init-file()
  #<compiled-function nil "...(10)" [init-file-had-error
load-user-init-file-p load-user-init-file nil] 2>()
  # (unwind-protect ...)
  call-with-condition-handler(#<compiled-function
(__load_init_file_arg__) "...(26)" [init-file-had-error
user-init-file __load_init_file_arg__ errstr
error-message-string message "Error in init file: %s" lwarn
initialization error "An error has occurred while loading
%s:\n\n%s\n\nBacktrace follows:\n\n%s\n\nTo ensure normal
operation, you should investigate the cause of the error\nin
your initialization file and remove it.  Use the `-debug-init'
option\nto XEmacs to enter the debugger when the error occurs
and investigate the\nexact problem."
backtrace-in-condition-handler-eliminating-handler t] 8>
#<compiled-function nil "...(10)" [init-file-had-error
load-user-init-file-p load-user-init-file nil] 2>)
  # (condition-case ... . ((error)))
  # bind (debug-on-error debug-on-error-from-init-file
debug-on-error-should-be-set debug-on-error-initial)
  load-init-file()
  # bind (command-line-args-left)
  command-line()
  # (condition-case ... . ((t (byte-code "	‡" [error-data
data nil] 1))))
  # bind (error-data)
  normal-top-level()
  # (condition-case ... . error)
  # (catch top-level ...)

As the reporter in

http://bugzilla.novell.com/show_bug.cgi?id=432404

wrote, there seems to be a problem with byte compiling any
startup file, also with custom.el or something like ~/.gnus.el

I have noticed problems myself years ago but ignored it because I
thought it doesn’t matter much whether such init files are byte
compiled or not.

I’m not sure whether the problems I saw some years ago are the
same
which I am reporting now, as far as I remember gnus in XEmacs did
startup correctly with a byte compiled ~/.gnus.el but there
were weird
problems later while using gnus. I don’t remember clearly, it
was so
long ago.

But now there seems to be definitely a reproducible problem with
byte compiling even a very simple ~/.xemacs/init.el.

Or is byte compiling such files not allowed?

(emacs-version) 
"XEmacs 21.5  (beta28) \"fuki\" [Lucid] (x86_64-suse-linux,
Mule) of Wed Aug 20 2008\
 on build18"

See also:

http://bugzilla.novell.com/show_bug.cgi?id=432404

Trying to reproduce the problem there with a minimal setup
I created a test user with a minimalistic .xemacs/init.el
and started xemacs and byte compiled the .xemacs/init.el file:

lmfabian@magellan:~> ls .xemacs
init.el  init.elc
lmfabian@magellan:~> cat .xemacs/init.el
(setq custom-file "~/.xemacs/custom.el")
(load "~/.xemacs/custom.el" t t)
lmfabian@magellan:~> 

Then when starting the same xemacs again I see the
following error message in the mini-buffer:

  Error: An error has occurred while loading
/home/lmfabian/.xemacs/init.elc:

And after typing RET I see the following Lisp backtrace in the
*Warnings* buffer:

(1) (initialization/error) An error has occurred while loading
/home/lmfabian/.xemac\
s/init.elc: 
 
Invalid byte code: reference 49936 to constants array out of
range 0, 3 
 
Backtrace follows: 
 
  byte-code("..." [custom-file "~/.xemacs/custom.el" load t] 4) 
  # (unwind-protect ...) 
  # (unwind-protect ...) 
  # (unwind-protect ...) 
  # (unwind-protect ...) 
  # (unwind-protect ...) 
  # (unwind-protect ...) 
  # (unwind-protect ...) 
  # (unwind-protect ...) 
  load-internal("/home/lmfabian/.xemacs/init.elc" t t t binary) 
  # bind (handler path nosuffix nomessage noerror filename) 
  load("/home/lmfabian/.xemacs/init.elc" t t t) 
  load-user-init-file() 
  #<compiled-function nil "...(10)" [init-file-had-error
load-user-init-file-p load-\
user-init-file nil] 2>() 
  # (unwind-protect ...) 
  call-with-condition-handler(#<compiled-function
(__load_init_file_arg__) "...(26)"\
 [init-file-had-error user-init-file __load_init_file_arg__
errstr error-message-str\
ing message "Error in init file: %s" lwarn initialization
error "An error has occurr\
ed while loading %s:\n\n%s\n\nBacktrace follows:\n\n%s\n\nTo
ensure normal operation\
, you should investigate the cause of the error\nin your
initialization file and rem\
ove it.  Use the `-debug-init' option\nto XEmacs to enter the
debugger when the erro\
r occurs and investigate the\nexact problem."
backtrace-in-condition-handler-elimina\
ting-handler t] 8> #<compiled-function nil "...(10)"
[init-file-had-error load-user-\
init-file-p load-user-init-file nil] 2>) 
  # (condition-case ... . ((error))) 
  # bind (debug-on-error debug-on-error-from-init-file
debug-on-error-should-be-set \
debug-on-error-initial) 
  load-init-file() 
  # bind (command-line-args-left) 
  command-line() 
  # (condition-case ... . ((t (byte-code "      ^PÂ\207"
[error-data data nil] 1)))) 
  # bind (error-data) 
  normal-top-level() 
  # (condition-case ... . error) 
  # (catch top-level ...) 
 
 
To ensure normal operation, you should investigate the cause
of the error 
in your initialization file and remove it.  Use the
`-debug-init' option 
to XEmacs to enter the debugger when the error occurs and
investigate the