<RANT> Why have we converted our sources to this bizarre Ibyte/Extbyte language? </RANT> For the first time in awhile, I built a pdumped XEmacs. This XEmacs happened to be 21.5, so I noticed that the way I usually run, with a symlink from a common bin directory to a build-specific install directory, could not find the .dmp file. (E.g. I install into the prefix /usr/local/xemacs-21.5-2003-09-07 and create a symbolic link in /usr/local/bin/xemacs-21.5 that points to /usr/local/xemacs-21.5-2003-09-07/bin/xemacs.) Stephen and I fixed this issue for 21.4 last December, but the fix never got ported to 21.5. I tried doing a straight port of the old patch, but xrealpath no longer exists. I started to convert to the new format, but now I'm getting a segfault in converting the filename. Here are the diffs --- /home/acs/cvsroot/xemacs-21.5/src/dumper.c 2003-05-09 16:02:39.000000000 -0400 +++ /opt/src/xemacs-21.5-2003-09-07-1646/src/dumper.c 2003-09-07 23:13:49.000000000 -0400 ＠＠ -1546,7 +1546,8 ＠＠ int pdump_load (const Extbyte *argv0) { - Extbyte exe_path[PATH_MAX]; + Extbyte exe_path[PATH_MAX]; + Extbyte real_exe_path[PATH_MAX]; #ifdef WIN32_NATIVE GetModuleFileNameA (NULL, exe_path, PATH_MAX); #else /* !WIN32_NATIVE */ ＠＠ -1617,7 +1618,11 ＠＠ } #endif /* WIN32_NATIVE */ - if (pdump_file_try (exe_path)) + /* Save exe_path because pdump_file_try() modifies it */ + strcpy(real_exe_path, exe_path); + if (pdump_file_try (exe_path) + || (qxe_realpath (real_exe_path, real_exe_path) + && pdump_file_try (real_exe_path))) { pdump_load_finish (); in_pdump = 0; And here is the stack backtrace which gets generated in the call to qxe_realpath: Program received signal SIGSEGV, Segmentation fault. 0x0808d36f in alloc_managed_lcrecord (lcrecord_list=0) at lrecord.h:1273 1273 DECLARE_LRECORD (lcrecord_list, struct lcrecord_list); (gdb) bt #0 0x0808d36f in alloc_managed_lcrecord (lcrecord_list=0) at lrecord.h:1273 #1 0x081915b2 in make_opaque_ptr (val=0x0) at /opt/src/xemacs-21.5-2003-09-07-1646-debug/src/opaque.c:161 #2 0x080d53c4 in record_unwind_protect_restoring_int (addr=0x0, val=0) at /opt/src/xemacs-21.5-2003-09-07-1646-debug/src/eval.c:5925 #3 0x080d5428 in internal_bind_int (addr=0x0, newval=0) at /opt/src/xemacs-21.5-2003-09-07-1646-debug/src/eval.c:5945 #4 0x0808f3c4 in begin_gc_forbidden () at /opt/src/xemacs-21.5-2003-09-07-1646-debug/src/alloc.c:4389 #5 0x081fa166 in dfc_convert_to_external_format (source_type=DFC_TYPE_DATA, source=0xbfffb700, coding_system=0, sink_type=DFC_TYPE_DATA, sink=0xbfffb6f8) at /opt/src/xemacs-21.5-2003-09-07-1646-debug/src/text.c:2835 #6 0x081f56ec in qxe_readlink (path=0x0, buf=0xbfffb770 "", bufsiz=4095) at /opt/src/xemacs-21.5-2003-09-07-1646-debug/src/sysdep.c:3087 #7 0x081a09b4 in readlink_and_correct_case (name=0x0, buf=0x0, size=0) at /opt/src/xemacs-21.5-2003-09-07-1646-debug/src/realpath.c:76 #8 0x081a0b68 in qxe_realpath (path=0xbfffc775 "/acs/bin/xemacs-21.5", resolved_path=0xbfffd800 "/home") at /opt/src/xemacs-21.5-2003-09-07-1646-debug/src/realpath.c:298 #9 0x080eb950 in pdump_load (argv0=0xbffffa7d "/home/acs/bin/xemacs-21.5") at /opt/src/xemacs-21.5-2003-09-07-1646-debug/src/dumper.c:1623 #10 0x080c8e72 in xemacs_21_5_b15_i686_pc_linux (argc=2, argv=0xbffff914, envp=0xbffff920, restart=0) at /opt/src/xemacs-21.5-2003-09-07-1646-debug/src/emacs.c:1176 #11 0x080ca3b3 in main (argc=0, argv=0x0, envp=0x0) at /opt/src/xemacs-21.5-2003-09-07-1646-debug/src/emacs.c:2895 #12 0x402677f7 in __libc_start_main () from /lib/i686/libc.so.6 I was surprised to find that qxe_realpath takes Ibytes as arguments, it's attempting to resolve an external filename, so why doesn't it take Extbytes? Can someone please explain to me how to convert my Extbyte path to an Ibyte *? Thank you, Vin