GNU bug report logs - #16099
MinGW build failure when srcdir is absolute and has "wrong" format

Previous Next

Package: emacs;

Reported by: Richard Copley <rcopley <at> gmail.com>

Date: Tue, 10 Dec 2013 12:14:01 UTC

Severity: normal

Found in version 24.3.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #42 received at 16099 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 16099 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Tue, 10 Dec 2013 18:25:11 +0000
[Message part 1 (text/plain, inline)]
On 10 Dec 2013 18:12, "Glenn Morris" <rgm <at> gnu.org> wrote:
>
>
> What's going on here:
>
>   Buffer is read-only: #<buffer cus-load.el>
>   [...]
>   Buffer is read-only: #<buffer finder-inf.el>
>   [...]
>   Opening output file: no such file or directory,
c:/c/emacs/trunk/lisp/loaddefs.el
>   [...]
>   loaddefs.el: No such file or directory
>
> ?

That certainly looks suspect, well spotted. I guess
"c:/c/emacs/trunk/lisp/loaddefs.el" is the value of
`generated-autoload-file' which is set a few lines up:

[...] --eval '(setq generated-autoload-file (expand-file-name
"/c/emacs/trunk/lisp/loaddefs.el"))' [...]

I think that's probably a bug (mixing MSYS- and native-style paths), but if
I had used a relative path to invoke the configure script, it would have
been a benign bug. I'll reconfigure using a relative path and try again.
[Message part 2 (text/html, inline)]

This bug report was last modified 11 years and 166 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.