[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Building Emacs from a new MinGW environment
From: |
Dani Moncayo |
Subject: |
Re: Building Emacs from a new MinGW environment |
Date: |
Sat, 14 Sep 2013 16:25:03 +0200 |
> The %emacs_dir% part was supposed to be expanded. If nothing else
> comes up from checking the installed packages, try to run the command
>
> temacs --batch --load loadup bootstrap
>
> under GDB, and see why the expansion doesn't happen.
Caveat: my knowledge of gdb and debugging emacs is almost zero :).
However, after a few hours, I think I've found out something.
I've looked for the first call to "Fexpand_file_name" which returns a
"bad" file name (bad = containing a literal "%emacs_dir%"). It is
this one:
#0 Fexpand_file_name (name=57476769, default_directory=57476785)
at C:/msys/home/dani/emacs/emacs.git/src/fileio.c:1437
#1 0x01119643 in Fexpand_file_name (name=57476753,
default_directory=57422161)
at C:/msys/home/dani/emacs/emacs.git/src/fileio.c:930
#2 0x011bf86f in init_callproc ()
at C:/msys/home/dani/emacs/emacs.git/src/callproc.c:1616
#3 0x010dad7c in main (argc=5, argv=0x972af8)
at C:/msys/home/dani/emacs/emacs.git/src/emacs.c:1325
The parameters of the call in frame #0 were:
(gdb) p SSDATA(name)
$1 = 0x36c4d50 <__register_frame_info+57429328>
"%emacs_dir%/share/emacs/24.3.50/etc/"
(gdb) p SSDATA(default_directory)
$3 = 0x36c4d7c <__register_frame_info+57429372>
"c:/msys/home/dani/emacs/build/src/"
The parameters of the call in frame #1 were:
(gdb) p SSDATA(name)
$4 = 0x36c4d48 <__register_frame_info+57429320> "GNU"
(gdb) p SSDATA(default_directory)
$5 = 0x36c4204 <__register_frame_info+57426436>
"%emacs_dir%/share/emacs/24.3.50/etc/"
IIUC, the function call at frame 0 failed to expand the default
directory passed to the function call at frame 1.
Now, It seems to me that the code responsible for the expansion of
"%emacs_dir%" is this snippet of "Fexpand_file_name":
/* If the file name has special constructs in it,
call the corresponding file handler. */
handler = Ffind_file_name_handler (name, Qexpand_file_name);
if (!NILP (handler))
{
handled_name = call3 (handler, Qexpand_file_name,
name, default_directory);
if (STRINGP (handled_name))
return handled_name;
error ("Invalid handler in `file-name-handler-alist'");
}
But I observe that the call to "Ffind_file_name_handler" returns
"Qnil", and therefore the expansion (the call to "call3") is not
carried out.
Debugging inside "Ffind_file_name_handler", I see that the "for" loop
is never entered.
Does this gives you a clue of what is failing? If you need more info,
just tell me what commands should I run.
--
Dani Moncayo
- Re: Building Emacs from a new MinGW environment, Dani Moncayo, 2013/09/13
- Re: Building Emacs from a new MinGW environment, Eli Zaretskii, 2013/09/14
- Re: Building Emacs from a new MinGW environment, Dani Moncayo, 2013/09/14
- Re: Building Emacs from a new MinGW environment,
Dani Moncayo <=
- Re: Building Emacs from a new MinGW environment, Eli Zaretskii, 2013/09/14
- Re: Building Emacs from a new MinGW environment, Dani Moncayo, 2013/09/14
- Re: Building Emacs from a new MinGW environment, Eli Zaretskii, 2013/09/14
- Re: Building Emacs from a new MinGW environment, Dani Moncayo, 2013/09/14
- Re: Building Emacs from a new MinGW environment, Eli Zaretskii, 2013/09/14
- Re: Building Emacs from a new MinGW environment, Dani Moncayo, 2013/09/14
- Re: Building Emacs from a new MinGW environment, Eli Zaretskii, 2013/09/14
- Re: Building Emacs from a new MinGW environment, Dani Moncayo, 2013/09/14
- Re: Building Emacs from a new MinGW environment, Dani Moncayo, 2013/09/14
- Re: Building Emacs from a new MinGW environment, Eli Zaretskii, 2013/09/15