Compiling xemacs with Visual Studio 2015 Community ('free') edition

[Henry S. Thompson]

Installed the above on my Windows 8.1 box, pulled the latest
(cb65bfaf7110) revision, imported the project file, and built it (from
inside VS2015, Debug x86 build).

The attached patch file got me to the point where the compilation
succeeded, but linking is a catastrophe, and I don't understand how to
fix it. Large numbers of _-prefixed fns are showing is unavailable,
but I can't see where they're coming from.

Attached are the patches necessary to get the compilation to complete,
and the config.inc I'm using. Probably some naive mistake there,
needs a new pair of eyes.

Note that I picked VS2015 because it's the latest available, and what
the Python project has chosen, even though all you can download at the
moment is an RC.

ht

[Sean MacLennan]

On Sun, 26 Jul 2015 19:58:09 +0100

Post by Henry S. Thompson
Installed the above on my Windows 8.1 box, pulled the latest
(cb65bfaf7110) revision, imported the project file, and built it (from
inside VS2015, Debug x86 build).
The attached patch file got me to the point where the compilation
succeeded, but linking is a catastrophe, and I don't understand how to
fix it. Large numbers of _-prefixed fns are showing is unavailable,
but I can't see where they're coming from.
Attached are the patches necessary to get the compilation to complete,
and the config.inc I'm using. Probably some naive mistake there,
needs a new pair of eyes.
Note that I picked VS2015 because it's the latest available, and what
the Python project has chosen, even though all you can download at the
moment is an RC.
ht

Could you list a couple of the _-prefixed functions. Usually the
problem is the other way around... they want _ functions instead of the
normal functions.

Cheers,
Sean

[Henry S. Thompson]

Post by Sean MacLennan
On Sun, 26 Jul 2015 19:58:09 +0100

Large numbers of _-prefixed fns are showing is unavailable, but I
can't see where they're coming from.

Could you list a couple of the _-prefixed functions. Usually the
problem is the other way around... they want _ functions instead of the
normal functions.

1> bscmake -nologo -oC:\C64\usr\local\src\xemacs-21.5-upstream\src\temacs.bsc @C:\C64\usr\local\src\xemacs-21.5-upstream\nt\obj\bscmake.tmp
1> del C:\C64\usr\local\src\xemacs-21.5-upstream\nt\obj\bscmake.tmp
1> link.exe @C:\Users\ht\AppData\Local\Temp\nm5FE7.tmp
...
1>win32.obj: error LNK2001: unresolved external symbol _memcpy
...
1>text.obj: error LNK2001: unresolved external symbol __imp__wcslen
...
1>win32.obj: error LNK2001: unresolved external symbol _strcmp

And so on -- dozens of symbols, most referenced from dozens of files.
Google/stackoverflow suggest this is something to do with the various
flavours of MSVCRT, but I'd expect VS to take care of that sort of
thing. . .

The compilations themselves all look like this:

cl -nologo -W3 -DSTRICT -Zi -Od -MDd -c -TP -IC:\C64\usr\local\src\xemacs-21.5-upstream\nt\inc -IC:\C64\usr\local\src\xemacs-21.5-upstream\src -I"c:\C64\usr\local\src\xemacs-21.5-64bit\nt\winlibs\xpm-3.4k" -I"c:\C64\usr\local\src\xemacs-21.5-64bit\nt\winlibs\xpm-3.4k\lib" -I"c:\C64\usr\local\src\xemacs-21.5-64bit\nt\winlibs\libpng-1.2.40" -I"c:\C64\usr\local\src\xemacs-21.5-64bit\nt\winlibs\zlib-1.2.3" -I"c:\C64\usr\local\src\xemacs-21.5-64bit\nt\winlibs\tiff-3.7.3\libtiff" -I"c:\C64\usr\local\src\xemacs-21.5-64bit\nt\winlibs\compface-1.5.1" -I"c:\C64\usr\local\src\xemacs-21.5-64bit\nt\winlibs\zlib-1.2.3" -I"c:\C64\usr\local\src\xemacs-21.5-64bit\nt\winlibs\db-4.3.28\build_win32" -I"c:\C64\usr\local\src\xemacs-21.5-64bit\nt\winlibs\postgresql-8.0.3\src\include" -I"c:\C64\usr\local\src\xemacs-21.5-64bit\nt\winlibs\postgresql-8.0.3\src\interfaces\libpq" -DHAVE_MS_WINDOWS -DHAVE_MENUBARS -DHAVE_SCROLLBARS -DHAVE_TOOLBARS -DHAVE_WIDGETS -DHAVE_DIALOGS -DHAVE_XPM -DFOR_MSW -DHA!
VE_PNG -DHAVE_TIFF -DHAVE_XFACE -DHAVE_ZLIB -DHAVE_DATABASE -DHAVE_BERKELEY_DB -DDB_H_FILE=\"db.h\" -DHAVE_POSTGRESQL -DHAVE_POSTGRESQLV7 -DLIBPQ_FE_H_FILE=\"libpq-fe.h\" -DHAVE_NATIVE_SOUND -DERROR_CHECK_ALL -DPDUMP -DUSE_KKCC -DSYSTEM_MALLOC -DDEBUG_XEMACS -D_DEBUG -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs -DNTDDI_VERSION=NTDDI_WIN2K -D_WIN32_WINNT=_WIN32_WINNT_WIN2K -D_CRT_NO_POSIX_ERROR_CODES -DHAVE_CONFIG_H -DPATH_VERSION=\"21.5-b34\" -DPATH_PROGNAME=\"xemacs\" -DEMACS_VERSION=\"21.5-b34\" -DEMACS_PROGNAME=\"xemacs\" -DSHEBANG_PROGNAME=\"xemacs-script\" -DSTACK_TRACE_EYE_CATCHER=xemacs_21_5_b34_i586_pc_win32 -DPATH_PREFIX=\""c:\\Program Files\\XEmacs\\XEmacs-21.5-b34"\" -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSION=34 -DXEMACS_CODENAME=\""kale"\" -DXEMACS_EXTRA_NAME=\"""\" -DEMACS_CONFIGURATION=\"i586-pc-win32\" C:\C64\usr\local\src\xemacs-21.5-upstream\src\win32.c -FoC:\C64\usr\local\src\xemacs-21.5-upstream\nt\obj\win32.ob!
j -FRC:\C64\usr\local\src\xemacs-21.5-upstream\nt\obj\win32.sb!
r -FdC:\
C64\usr\local\src\xemacs-21.5-upstream\nt\obj\temacs.pdb

Thanks for any suggestions you can offer,

ht

[Henry S. Thompson]

Post by Henry S. Thompson

Post by Sean MacLennan
On Sun, 26 Jul 2015 19:58:09 +0100

Large numbers of _-prefixed fns are showing is unavailable, but I
can't see where they're coming from.

Could you list a couple of the _-prefixed functions. Usually the
problem is the other way around... they want _ functions instead of the
normal functions.

1> del C:\C64\usr\local\src\xemacs-21.5-upstream\nt\obj\bscmake.tmp
...
1>win32.obj: error LNK2001: unresolved external symbol _memcpy
...
1>text.obj: error LNK2001: unresolved external symbol __imp__wcslen
...
1>win32.obj: error LNK2001: unresolved external symbol _strcmp
And so on -- dozens of symbols, most referenced from dozens of files.
Google/stackoverflow suggest this is something to do with the various
flavours of MSVCRT, but I'd expect VS to take care of that sort of
thing. . .

OK, by creating a tiny test project and comparing its linking
behaviour, I identified at least four fixable problems in xemacs.mak:

1) _strlen and friends are defined in a previously unused library ucrt(d).lib;
2) _memcpy and friends are defined in a previously
unused library vcruntime(d).lib;
3) We don't have manifest files (yet), so the calls to mt -manifest...
need to be conditionalized on their existence, i.e. by prefixing
with
@if exist $@.manifest
4) Some of the extension libraries, compiled against older VS
version(s), reference no-longer-supported symbols, so config.inc
changed to avoid postgresql, png and tiff for the time being.

Having made those changes, I can compile and get past all the earlier
missing symbols, but alas Xpm.lib is _also_ stale, and required, so
I'll have to stop and rebuild that before further progress.

ht

[Henry S. Thompson]

Post by Henry S. Thompson
...
Having made those changes, I can compile and get past all the earlier
missing symbols, but alas Xpm.lib is _also_ stale, and required, so
I'll have to stop and rebuild that before further progress.

Stopped, rebuilt, further fixes to xemacs.mak (how did this ever
work?), now compiles, links and . . . crashes in temacs.exe

This one looks like a real failure, out of my depth here:

Debug Assertion Failed!

Program:...temacs.exe
minkernel\crts\ucrt\src\appcrt\lowio\isatty.cpp
Line: 17

Expression: (fh >= 0 && (unsigned)fh < (unsigned)_nhandle)

The bottom of the stack is at

rtnval = fwrite (b, size, nitem, stream);

in sysdep.c:retry_fwrite

The attached patch file includes more changes to xemacs.mak than the
one previously sent.

ht

[Henry S. Thompson]

Post by Henry S. Thompson
Stopped, rebuilt, further fixes to xemacs.mak (how did this ever
work?), now compiles, links and . . . crashes in temacs.exe
Debug Assertion Failed!
Program:...temacs.exe
minkernel\crts\ucrt\src\appcrt\lowio\isatty.cpp
Line: 17

Bizarrely, _not_ really temacs.exe, but some odd side-effect of
running under i.exe. Just running temacs.exe by itself works just
fine, just the log goes in a popup.

Anyone understand that old weird bit of code?

ht

[Henry S. Thompson]

TL;DR: More progress, another patch file with some errors removed.

I think the attached now builds cleanly all the way through to dumping
xemacs.exe and then trying to use it, which fails (see below).

The problem with i.exe remains, but the workaround of just removing it
works, _if_ you are vigilant, and whenever an popup window with output
from temacs looks like it's finished, you check for a small hidden
alert saying "XEmacs exited" and requiring a click on OK.

The xemacs crash is reported as follows by VS2015

Unhandled exception at 0x00BCB1AC in xemacs.exe: 0xC0000005: Access
violation writing location 0x00EAE6A4.

The VS2015 backtrace is

xemacs.exe!pdump_load_finish() Line 2350 C++
xemacs.exe!pdump_load(const wchar_t * argv0) Line 2793 C++
xemacs.exe!xemacs_21_5_b34_i586_pc_win32(int argc, wchar_t * * argv, wchar_t * * unused_envp, int restart) Line 1408 C++
xemacs.exe!main(int argc, char * * argv, char * * unused_envp) Line 3204 C++

Hope someone can reproduce, then help.

ht

[Note about the attached patches, wrt xemacs.mak: I'm sure the way I'm
handling the extra libraries is sub-optimal, but I don't understand
how this ever worked in the past. I hope someone who does understand
will fix this in a cleaner way.]