[Top][All Lists]

[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

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


>   (gdb) xstring

$3 = (struct Lisp_String *) 0x36d0710 <__register_frame_info+57476880>

> 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

Attachment: epaths.diff
Description: Binary data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]