Fixed by Stephen J. Turnbull on 2011-05-02:
http://article.gmane.org/gmane.emacs.xemacs.patches/13007

Not fixed in xemacs 21.5.30.

After some fun debugging today, helped by Aidan on IRC, I've
found that the problem is related to optimization. With -O2
and GCC 4.1.2 on x86 the pdump_file_try function gets fully
inlined in pdump_load (both in dumper.c) and this clobbers the
exe_path variable to become an empty string. Obviously that
thwarts the attempts in pdump_file_try and the dump file is
not found.

Removing the 'static' declaration from pdump_file_try is
enough to let the build succeed.

That was what the link was initially: /usr/bin/xemacs ->
xemacs-21.5-b28. That didn't make a difference. The same setup
works fine on amd64, but don't really see how this could be
related to 64bit vs. 32bit differences. Then again, maybe that
is just a red herring.

I guess it's time to create a good debug version of xemacs and
step throught the code in emacs.c to see what happens exactly.
Not sure how easy that will be and when I'll have time for
that, though.

Hans de Graaff writes:
 > 
 > Hans de Graaff <graaff@gentoo.org> added the comment:
 > 
 > Here is the output from 'ls -l /usr/bin/xemacs*'
 > 
 > lrwxrwxrwx 1 root root      24 2008-04-25 07:26
 > /usr/bin/xemacs -> /usr/bin/xemacs-21.5-b28
 > -rwxr-xr-x 1 root root 3884264 2008-04-22 20:35
 > /usr/bin/xemacs-21.5-b28
 > -rw-r--r-- 1 root root 5150792 2008-04-22 20:35
 > /usr/bin/xemacs-21.5-b28-4807ddb0.dmp

Try linking /usr/bin/xemacs -> xemacs-21.5-b28 and see if that helps.
If so, it would indicate problems in our algorith for finding the dump
file and/or getting the truename of `xemacs'.

Here is the output from 'ls -l /usr/bin/xemacs*'

lrwxrwxrwx 1 root root      24 2008-04-25 07:26
/usr/bin/xemacs -> /usr/bin/xemacs-21.5-b28
-rwxr-xr-x 1 root root 3884264 2008-04-22 20:35
/usr/bin/xemacs-21.5-b28
-rw-r--r-- 1 root root 5150792 2008-04-22 20:35
/usr/bin/xemacs-21.5-b28-4807ddb0.dmp

'xemacs -sd' gives me 4807ddb0, matching the dump file. Not
surprising, since everything works fine if I start xemacs
without the explicit path, and I've confirmed that the right
dump file gets loaded with strace. It's just when using
/usr/bin/xemacs that things get really confused.

Hans,

in my setup (that works), the bin/ directory that is in my
path contains the following symlinks:

xemacs@ -> ../xemacs-21.5-newgc/bin/xemacs
xemacs.dmp@ ->
../xemacs-21.5-newgc/bin/xemacs-21.5-b28-47b1dfed.dmp

Does this look similar on your machine?

The dump id that is the last part of the dump file's name has
to match the dump id the xemacs binary is expecting:

$ xemacs -sd
47b1dfed

Please check if this is the case on your system.  It happened
to me a few times a while ago that after re-building and
re-installing xemacs the wrong dump file is linked.  IIRC,
this caused the same problems that you are seeing.  Note that
the dump id is re-generated on every build, so there is always
only one dump file that one xemacs accepts.

Please let me know if this helps; if not, I'll dig deeper.

Thanks for providing some pointers to help debug this issue. 

/usr/bin/xemacs is a symlink to xemacs-21.5-b28 in the same
directory. This is also where the dump file is located. 

Comparing the strace output from both runs, I see several
attempts to open xemacs according to my PATH variable when
using 'xemacs', but I see three open attempts with an empty
path when using '/usr/bin/xemacs': open("", O_RDONLY).

So it looks like the wrong path is taken in the code handling
Vinvocation_name (~ emacs.c:2600). I briefly suspected that it
might be caused by a relative symlink, but the same thing
happens with a absolute symlink (ie xemacs ->
/usr/bin/xemacs-21.5-b28).

Both the amd64 (working) and x86 (broken) instance are
configured with --with-newgc. No explicit --with-dump-in-exec
is given to configure either way.

Both builds give the same output:

Other Features:
  Inhibiting IPv6 canonicalization at startup.
  Compiling in support for dynamic shared object modules.
  Using the new GC mark algorithms (KKCC).
  WARNING:
---------------------------------------------------------
  WARNING: The new algorithms are experimental. They are
enabled by
  WARNING: default for this release. Use `--disable-kkcc' to
  WARNING: turn it off.
  WARNING:
---------------------------------------------------------
  Using the new incremental garbage collector and the new
allocator.
  Using POSIX sigaction() to install fault handler.
  Using the new portable dumper.
  Compiling in support for extra debugging code.
  Compiling in support for runtime error checking.

This message normally means that xemacs can't find its dump
file.  Are there any symlinks or automounts involved in
/usr/bin, or are there any cross-directory symlinks from
/usr/bin/xemacs to the binary?  Where is the dump file?

This should not happen if xemacs is configured with the
--with-dump-in-exec flag.  Are you configuring with
--with-newgc=no?

Assigning to Marcus, since that is only disabled with
--with-newgc=no and I think this is the probable cause.

With xemacs 21.5b28 the following command does nothing as
expected:

  xemacs -batch -vanilla -quit

But running this command:

  /usr/bin/xemacs -batch -vanilla -quit

Gives this output:

  temacs can only be run in -batch mode.

I've checked that I only have on xemacs in my PATH and that it
is located in /usr/bin, so this is the same instance of xemacs
that is started. This only happens on x86, I cannot reproduce
the problem on amd64.