bug#28493: 26.0.50; Build failure with latest MSYS2

bug#28493: 26.0.50; Build failure with latest MSYS2

[Richard Copley]

After a recent MSYS2 upgrade, Emacs fails to build.
The error is

./temacs --batch  --load loadup bootstrap
make[1]: *** [Makefile:738: bootstrap-emacs.exe] Error 127

Running the temacs in question from a native command prompt
gives a message box to the effect "ScriptFreeCache not found
in GDI32.dll".

The doc for ScriptFreeCache
<https://msdn.microsoft.com/en-us/library/windows/desktop/dd319121(v=vs.85).aspx>
has this note:

[Important] Starting with Windows 8: To maintain the ability to run on
Windows 7, a module that uses Uniscribe must specify Usp10.lib before
gdi32.lib in its library list.

If I re-link temacs.exe using the same command line as the Makefile
uses, except for moving "-lusp10" to just before "lgdi32", then
start "Make" again, the build succeeds.

This happens when I build on Windows 7 and not on Windows 10.
I don't understand why the MSYS2 update is relevant to this.
Maybe it's not.

In GNU Emacs 26.0.50 (build 2, x86_64-w64-mingw32)
 of 2017-09-14 built on 60678UHB
Repository revision: ec5c287fa86a04baa55eac7a2388bd10a0cff498
Windowing system distributor 'Microsoft Corp.', version 6.1.7601
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
C-c C-c is undefined

Configured using:
 'configure --config-cache --with-modules --without-pop 'CFLAGS=-Og
 -ggdb3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS MODULES

Important settings:
  value of $LANG: ENG
  locale-coding-system: cp1252

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message subr-x puny seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils elec-pair time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win
w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote w32notify w32 multi-tty make-network-process emacs)

Memory information:
((conses 16 96936 7232)
 (symbols 56 20140 1)
 (miscs 48 41 87)
 (strings 32 29576 1455)
 (string-bytes 1 747132)
 (vectors 16 13995)
 (vector-slots 8 482004 10070)
 (floats 8 50 72)
 (intervals 56 233 0)
 (buffers 992 11))

bug#28493: 26.0.50; Build failure with latest MSYS2

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Mon, 18 Sep 2017 15:12:14 +0100
> 
> After a recent MSYS2 upgrade, Emacs fails to build.
> The error is
> 
> ./temacs --batch  --load loadup bootstrap
> make[1]: *** [Makefile:738: bootstrap-emacs.exe] Error 127
> 
> Running the temacs in question from a native command prompt
> gives a message box to the effect "ScriptFreeCache not found
> in GDI32.dll".
> 
> The doc for ScriptFreeCache
> <https://msdn.microsoft.com/en-us/library/windows/desktop/dd319121(v=vs.85).aspx>
> has this note:
> 
> [Important] Starting with Windows 8: To maintain the ability to run on
> Windows 7, a module that uses Uniscribe must specify Usp10.lib before
> gdi32.lib in its library list.

But you are on Windows 7, not 8, right?

In what import library do you have ScriptFreeCache? in libgdi32.a or
in libusp10.a?  I see it in the latter?

> I don't understand why the MSYS2 update is relevant to this.

What does "MSYS2 update" mean, in practical terms?  Which files get
updated?  Does that include import libraries in lib/?

bug#28493: 26.0.50; Build failure with latest MSYS2

[Richard Copley]

On 18 September 2017 at 19:14, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> Date: Mon, 18 Sep 2017 15:12:14 +0100
>>
>> After a recent MSYS2 upgrade, Emacs fails to build.
>> The error is
>>
>> ./temacs --batch  --load loadup bootstrap
>> make[1]: *** [Makefile:738: bootstrap-emacs.exe] Error 127
>>
>> Running the temacs in question from a native command prompt
>> gives a message box to the effect "ScriptFreeCache not found
>> in GDI32.dll".
>>
>> The doc for ScriptFreeCache
>> <https://msdn.microsoft.com/en-us/library/windows/desktop/dd319121(v=vs.85).aspx>
>> has this note:
>>
>> [Important] Starting with Windows 8: To maintain the ability to run on
>> Windows 7, a module that uses Uniscribe must specify Usp10.lib before
>> gdi32.lib in its library list.
>
> But you are on Windows 7, not 8, right?

Right. I took it to mean "Starting with [the] Windows 8 [SDK]", but
your guess is as good as mine. Probably best to ignore it. I mentioned
it to tell you where I got the idea of shuffling the linker arguments.

Maybe it isn't relevant at all. Could be an unrelated and independent
change in MinGW-W64, or some other factor I've ignored.

> In what import library do you have ScriptFreeCache? in libgdi32.a or
> in libusp10.a?  I see it in the latter?

Both?

$ nm libgdi32.a
[...]
dqeobs00686.o:
0000000000000000 b .bss
0000000000000000 d .data
0000000000000000 i .idata$4
0000000000000000 i .idata$5
0000000000000000 i .idata$6
0000000000000000 i .idata$7
0000000000000000 t .text
0000000000000000 I __imp_ScriptFreeCache
                 U _head_lib64_libgdi32_a
0000000000000000 T ScriptFreeCache
[...]

$ nm libusp10.a
[...]
dmovds00006.o:
0000000000000000 b .bss
0000000000000000 d .data
0000000000000000 i .idata$4
0000000000000000 i .idata$5
0000000000000000 i .idata$6
0000000000000000 i .idata$7
0000000000000000 t .text
0000000000000000 I __imp_ScriptFreeCache
                 U _head_lib64_libusp10_a
0000000000000000 T ScriptFreeCache
[...]

>> I don't understand why the MSYS2 update is relevant to this.
>
> What does "MSYS2 update" mean, in practical terms?  Which files get
> updated?  Does that include import libraries in lib/?

Yes, the import libraries are new. (I just looked at the last-modified
time of the files. If you need details please ask.)

bug#28493: 26.0.50; Build failure with latest MSYS2

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Mon, 18 Sep 2017 21:06:31 +0100
> Cc: 28493@debbugs.gnu.org
> 
> > In what import library do you have ScriptFreeCache? in libgdi32.a or
> > in libusp10.a?  I see it in the latter?
> 
> Both?
> 
> $ nm libgdi32.a
> [...]
> dqeobs00686.o:
> 0000000000000000 b .bss
> 0000000000000000 d .data
> 0000000000000000 i .idata$4
> 0000000000000000 i .idata$5
> 0000000000000000 i .idata$6
> 0000000000000000 i .idata$7
> 0000000000000000 t .text
> 0000000000000000 I __imp_ScriptFreeCache
>                  U _head_lib64_libgdi32_a
> 0000000000000000 T ScriptFreeCache
> [...]
> 
> $ nm libusp10.a
> [...]
> dmovds00006.o:
> 0000000000000000 b .bss
> 0000000000000000 d .data
> 0000000000000000 i .idata$4
> 0000000000000000 i .idata$5
> 0000000000000000 i .idata$6
> 0000000000000000 i .idata$7
> 0000000000000000 t .text
> 0000000000000000 I __imp_ScriptFreeCache
>                  U _head_lib64_libusp10_a
> 0000000000000000 T ScriptFreeCache
> [...]

Interesting.  Do you have pexports.exe or some other tool that can
display the exports of a DLL?  (Not sure pexports supports 64-bit
DLLs, though.)  If so, can you look in your gdi32.dll and see whether
it really exports this function?  If it doesn't, then this looks like
a problem with the import libraries, although I see no problem in
changing the order of the link command line to fix it.

bug#28493: 26.0.50; Build failure with latest MSYS2

[Richard Copley]

On 19 September 2017 at 05:07, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> Date: Mon, 18 Sep 2017 21:06:31 +0100
>> Cc: 28493@debbugs.gnu.org
>>
>> > In what import library do you have ScriptFreeCache? in libgdi32.a or
>> > in libusp10.a?  I see it in the latter?
>>
>> Both?
>>
>
> Interesting.  Do you have pexports.exe or some other tool that can
> display the exports of a DLL?  (Not sure pexports supports 64-bit
> DLLs, though.)  If so, can you look in your gdi32.dll and see whether
> it really exports this function?  If it doesn't, then this looks like
> a problem with the import libraries, although I see no problem in
> changing the order of the link command line to fix it.

Yes, the symbol is exported from both DLLs.

bug#28493: 26.0.50; Build failure with latest MSYS2

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Tue, 19 Sep 2017 08:32:15 +0100
> Cc: 28493@debbugs.gnu.org
> 
> > Interesting.  Do you have pexports.exe or some other tool that can
> > display the exports of a DLL?  (Not sure pexports supports 64-bit
> > DLLs, though.)  If so, can you look in your gdi32.dll and see whether
> > it really exports this function?  If it doesn't, then this looks like
> > a problem with the import libraries, although I see no problem in
> > changing the order of the link command line to fix it.
> 
> Yes, the symbol is exported from both DLLs.

OK, thanks.  I've changed the order of the libraries, so the problem
should now be fixed on the emacs-26 branch.

bug#28493: 26.0.50; Build failure with latest MSYS2

[Richard Copley]

On 19 September 2017 at 18:33, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> Date: Tue, 19 Sep 2017 08:32:15 +0100
>> Cc: 28493@debbugs.gnu.org
>>
>> > Interesting.  Do you have pexports.exe or some other tool that can
>> > display the exports of a DLL?  (Not sure pexports supports 64-bit
>> > DLLs, though.)  If so, can you look in your gdi32.dll and see whether
>> > it really exports this function?  If it doesn't, then this looks like
>> > a problem with the import libraries, although I see no problem in
>> > changing the order of the link command line to fix it.
>>
>> Yes, the symbol is exported from both DLLs.
>
> OK, thanks.  I've changed the order of the libraries, so the problem
> should now be fixed on the emacs-26 branch.

Thank you, confirmed it works for me.

bug#28493: 26.0.50; Build failure with latest MSYS2

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Tue, 19 Sep 2017 19:27:17 +0100
> Cc: 28493@debbugs.gnu.org
> 
> > OK, thanks.  I've changed the order of the libraries, so the problem
> > should now be fixed on the emacs-26 branch.
> 
> Thank you, confirmed it works for me.

Thanks, closing.