Ibyte, etc
<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