[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 21:57:26 +0200 |
> What is the value of srcdir in top-level Makefile?
it is
/home/dani/emacs/emacs.git
and FWIW, msys_to_w32 is
sed -e 's,\\,/,g' -e 's,^/\([A-Za-z]\)/,\1:/,'
and strangely the printed value of w32srcdir is an empty string. It
strange because:
* The output of the command employed to produce its value (echo
"${srcdir}" | ${msys_to_w32}) is "/home/dani/emacs/emacs.git".
* The occurrences of "@SRC@" in epaths.nt are actually replaced by
that string ("/home/dani/emacs/emacs.git") when written to epaths.h.
I'm attaching the diff between these two files.
BTW, I don't understand why there are two "$" in
"/^.*#/s|@SRC@|$${w32srcdir}|g", unlike the two previous lines (which
should be similar, I think).
>> > set auto-load safe-path c:/msys/home/dani
>> >
>> > (I always disable this nuisance by using "/" as the argument.)
>>
>> I just tried that too. The warning disappears, but the xtype/xstring
>> commands remain undefined.
>
> "source ./gdbinit" inside GDB should do the trick.
Doing "source ./.gdbinit" didn't solve the problem, but I saw that the
contents of that file ("src/.gdbinit" from the build directory) are
this single line:
source /home/dani/emacs/emacs.git/src/.gdbinit
so it occurred to me that perhaps giving that command to gdb could do
the trick. And yes, it did. So here we go:
> If that doesn't work, perhaps PATH_DUMPLOADSEARCH has the wrong value
> (it comes from src/epaths.h). 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
$1 = 57476881
> (gdb) xtype
Lisp_String
> (gdb) xstring
$3 = (struct Lisp_String *) 0x36d0710 <__register_frame_info+57476880>
"c:/msys/home/dani/emacs/build/src/%emacs_dir%/share/emacs/24.3.50/etc/gnu"
> If the result of 'xstring' indeed shows the etc subdirectory of your
> Emacs source tree, then ....
No, the problem is already there: that path is wrong, obviously.
--
Dani Moncayo
epaths.diff
Description: Binary data
- 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, 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 <=
- 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
- Re: Building Emacs from a new MinGW environment, Eli Zaretskii, 2013/09/16
- Re: Building Emacs from a new MinGW environment, Dani Moncayo, 2013/09/16
- Re: Building Emacs from a new MinGW environment, Eli Zaretskii, 2013/09/16
- Re: Building Emacs from a new MinGW environment, Dani Moncayo, 2013/09/16