[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 17:42:28 +0200 |
> You need to step further down into init_callproc. It should correctly
> initialize Vdata_directory here:
>
> if (data_dir == 0)
> {
> Lisp_Object tem, tem1, srcdir;
>
> srcdir = Fexpand_file_name (build_string ("../src/"),
> build_string (PATH_DUMPLOADSEARCH));
> tem = Fexpand_file_name (build_string ("GNU"), Vdata_directory);
> tem1 = Ffile_exists_p (tem);
> if (!NILP (Fequal (srcdir, Vinvocation_directory)) || NILP (tem1))
> {
> Lisp_Object newdir;
> newdir = Fexpand_file_name (build_string ("../etc/"),
> build_string (PATH_DUMPLOADSEARCH));
> tem = Fexpand_file_name (build_string ("GNU"), newdir);
> tem1 = Ffile_exists_p (tem);
> if (!NILP (tem1))
> Vdata_directory = newdir; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> }
> }
>
The sentence you marked doesn't get executed, because "NILP(tem1)" is 1.
> If that doesn't work, perhaps PATH_DUMPLOADSEARCH has the wrong value
> (it comes from src/epaths.h).
It's defined like this:
#define PATH_DUMPLOADSEARCH "/home/dani/emacs/emacs.git/lisp"
Although that path doesn't have a literal "%emacs_dir%", I don't know
if it is correct, because it's relative to my MSYS (which is installed
in "c:\msys").
And BTW, looking at the file, I see many strings including a literal
"%emacs_dir%", e.g.:
#define PATH_LOADSEARCH
"%emacs_dir%/share/emacs/24.3.50/lisp;%emacs_dir%/share/emacs/24.3.50/leim"
I don't know if that is correct either.
> If PATH_DUMPLOADSEARCH looks OK (it
> should not have any %emacs_dir% in it, then look at the value of 'tem'
> 3 lines above the line I marked:
>
> (gdb) p tem
> (gdb) xtype
> (gdb) xstring
(gdb) p tem
$1 = 57503793
(gdb) xtype
Undefined command: "xtype". Try "help".
(gdb) xstring
Undefined command: "xstring". Try "help".
I glanced over etc/DEBUG, and saw this:
Some GDB versions by default do not automatically load .gdbinit files
in the directory where you invoke GDB. With those versions of GDB,
you will see a warning when GDB starts, like this:
warning: File ".../src/.gdbinit" auto-loading has been declined by
your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
There are several ways to overcome that difficulty, they are all
described in the node "Auto-loading safe path" in the GDB user manual.
and after looking at that node in the GDB manual, I created a file
~/.gdbinit with this line:
add-auto-load-safe-path C:\msys\home\dani
That removes the warning issued by gdb at startup, but the "xtype" and
"xstring" commands remain unknown to gdb. What am I doing wrong?
> If the result of 'xstring' indeed shows the etc subdirectory of your
> Emacs source tree, then perhaps the trouble happens inside
> Ffile_exists_p: it should return non-nil in this case. You can
> display its result:
>
> (gdb) p tem1
> (gdb) xtype
> (gdb) xsymbol
--
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, 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 <=
- 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
- Re: Building Emacs from a new MinGW environment, Eli Zaretskii, 2013/09/15
- Re: Building Emacs from a new MinGW environment, Dani Moncayo, 2013/09/16