Compilation problems with latest MSVC

Compilation problems with latest MSVC

[Eli Zaretskii]

It seems like latest versions of MSVC are incompatible with the Emacs
build procedure (MSVC 6 compiles the current CVS just fine).  See the
error messages below; this is with Visual Studio 2005 Express Edition,
the MS ``freeware'' distribution.

I could try working on these when I have time, but the question is: do
we care?  Is it enough to say that the last version of MSVC we support
is v6?  (Does anyone know if Studio 7 is okay?)

    >nmake bootstrap

    Microsoft (R) Program Maintenance Utility   Version 7.00.8882
    Copyright (C) Microsoft Corp 1988-2000. All rights reserved.

	    cl -I. -DWIN32_LEAN_AND_MEAN -D_WIN32_WINNT=0x0400 -nologo -D_X86_=1 -c -Zel -W2 -H63 -Oxsb2 -Oy- -G6dF -Zp8 -Zi -Di386  -D_CRTAPI1=_cdecl -Foobj-spd/i386\ addsection.c
    cl : Command line warning D9035 : option 'Ze' has been deprecated and will be removed in a future release
    cl : Command line warning D9035 : option 'H' has been deprecated and will be removed in a future release
    cl : Command line warning D9002 : ignoring unknown option '-G6'
    addsection.c
	    link -out:obj-spd/i386/addsection.exe  -nologo -release -incremental:no -version:3.10 -swaprun:cd -swaprun:net setargv.obj -debug:full -debugtype:both obj-spd/i386/addsection.obj libc.lib  oldnames.lib user32.lib
    LINK : warning LNK4224: /DEBUG:FULL is no longer supported;  ignored
    LINK : fatal error LNK1117: syntax error in option 'debugtype:both'
    NMAKE : fatal error U1077: 'link' : return code '0x45d'
    Stop.

The compiler identifies itself as follows:

    Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86

Re: Compilation problems with latest MSVC

[Lennart Borgman]

Eli Zaretskii wrote:
> It seems like latest versions of MSVC are incompatible with the Emacs
> build procedure (MSVC 6 compiles the current CVS just fine).  See the
> error messages below; this is with Visual Studio 2005 Express Edition,
> the MS ``freeware'' distribution.
> 
> I could try working on these when I have time, but the question is: do
> we care?  Is it enough to say that the last version of MSVC we support
> is v6?  (Does anyone know if Studio 7 is okay?)


I think it would be good to be able to compile with MSVC 7 too. I 
sometimes wonder if strange problems I see have something to do with 
bugs in the gcc compiler.

I am not saying that there are any problems with the gcc compiler. The 
problems I see are stability problems on my pc. I hoped they would be 
gone with my new pc using xp, but I have seen some problems again. Of 
course I have no idea which program causes this, but it would be fine to 
sometimes be able to run Emacs compiled with MSVC and see if that makes 
any difference. (The instabilities are very rare however so it is very 
hard to find out what is wrong. Probably some resource problem.)

Re: Compilation problems with latest MSVC

[David Robinow]

On 12/24/06, Eli Zaretskii <eliz@gnu.org> wrote:
> It seems like latest versions of MSVC are incompatible with the Emacs
> build procedure (MSVC 6 compiles the current CVS just fine).  See the
> error messages below; this is with Visual Studio 2005 Express Edition,
> the MS ``freeware'' distribution.
>
> I could try working on these when I have time, but the question is: do
> we care?  Is it enough to say that the last version of MSVC we support
> is v6?  (Does anyone know if Studio 7 is okay?)
Both Visual Studio .NET and Visual Studio .NET 2003 work fine. I've
been compiling Emacs  with them both since they came out.
  There is a warning that debugtype:both is no longer supported.  I
don't remember which type it actually uses.  As shown below, this
warning became an error in Visual Studio 2005.
>
>     >nmake bootstrap
>
>     Microsoft (R) Program Maintenance Utility   Version 7.00.8882
>     Copyright (C) Microsoft Corp 1988-2000. All rights reserved.
>
>             cl -I. -DWIN32_LEAN_AND_MEAN -D_WIN32_WINNT=0x0400 -nologo -D_X86_=1 -c -Zel -W2 -H63 -Oxsb2 -Oy- -G6dF -Zp8 -Zi -Di386  -D_CRTAPI1=_cdecl -Foobj-spd/i386\ addsection.c
>     cl : Command line warning D9035 : option 'Ze' has been deprecated and will be removed in a future release
>     cl : Command line warning D9035 : option 'H' has been deprecated and will be removed in a future release
>     cl : Command line warning D9002 : ignoring unknown option '-G6'
>     addsection.c
>             link -out:obj-spd/i386/addsection.exe  -nologo -release -incremental:no -version:3.10 -swaprun:cd -swaprun:net setargv.obj -debug:full -debugtype:both obj-spd/i386/addsection.obj libc.lib  oldnames.lib user32.lib
>     LINK : warning LNK4224: /DEBUG:FULL is no longer supported;  ignored
>     LINK : fatal error LNK1117: syntax error in option 'debugtype:both'
>     NMAKE : fatal error U1077: 'link' : return code '0x45d'
>     Stop.
>
> The compiler identifies itself as follows:
>
>     Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86
Visual Studio 6:  Version 12.00.8168   MSC_VER == 1200   Linker
version 6.00.8477
                          NMAKE_VER = 6.00.8168.0

Visual Studio .NET: Version 13.00.9466   Linker version 7.00.9466

Re: Compilation problems with latest MSVC

[David Robinow]

On 12/28/06, David Robinow <drobinow@gmail.com> wrote:
> On 12/24/06, Eli Zaretskii <eliz@gnu.org> wrote:
> > It seems like latest versions of MSVC are incompatible with the Emacs
> > ....
 Sorry. Fumble-fingers interrupted my previous post.
 Below are values for distributed versions of Visual Studio. It seems
some hacking on nmake.defs and makefile.w32-in should be able to
eliminate the warnings.

Visual Studio 6: CL Version 12.00.8168  MSC_VER = 1200
         Linker version 6.00.8477      _NMAKE_VER = 6.00.8168.0

Visual Studio .NET: CL Version 13.00.9466  MSC_VER = 1300
         Linker version 7.00.9466      _NMAKE_VER = 7.0.9466

Visual Studio .NET 2003: CL Version 13.10.3077  MSC_VER = 1310
         Linker vers. 7.10.3077      _NMAKE_VER = 7.10.3077

I tried to get the free-beer 2005 compiler to work about a month ago.
I  edited out the offending debugtype:both and got quite a bit
farther. However, I had some other problem (which I can't remember
now) and ran out of time to play with it.
 I'll try to report back after the first of the year.

Re: Compilation problems with latest MSVC

[Eli Zaretskii]

> Date: Thu, 28 Dec 2006 22:01:31 -0500
> From: "David Robinow" <drobinow@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> On 12/28/06, David Robinow <drobinow@gmail.com> wrote:
> > On 12/24/06, Eli Zaretskii <eliz@gnu.org> wrote:
> > > It seems like latest versions of MSVC are incompatible with the Emacs
> > > ....
>  Sorry. Fumble-fingers interrupted my previous post.
>  Below are values for distributed versions of Visual Studio. It seems
> some hacking on nmake.defs and makefile.w32-in should be able to
> eliminate the warnings.

If you can suggest a safe way of making these work for both VS 6 and
the later versions, we could consider installing the changes before
the release.  TIA

> Visual Studio 6: CL Version 12.00.8168  MSC_VER = 1200
>          Linker version 6.00.8477      _NMAKE_VER = 6.00.8168.0
> 
> Visual Studio .NET: CL Version 13.00.9466  MSC_VER = 1300
>          Linker version 7.00.9466      _NMAKE_VER = 7.0.9466
> 
> Visual Studio .NET 2003: CL Version 13.10.3077  MSC_VER = 1310
>          Linker vers. 7.10.3077      _NMAKE_VER = 7.10.3077

Thanks.  If nothing else, we should probably detect MSC_VER 1400 and
warn that it's unsupported.

> I tried to get the free-beer 2005 compiler to work about a month ago.
> I  edited out the offending debugtype:both and got quite a bit
> farther. However, I had some other problem (which I can't remember
> now) and ran out of time to play with it.

I worked on that, and had quite a few more problems (related to the
changes in the system headers which come with VS 2005 and to the fact
that there's no single-threaded C library anymore).  I solved those,
but then hit a brick wall when emacs-bootstrap built but crashed
during dumping.  I don't have time to debug the crash, so unless
someone else figures out how to solve it, I guess we will just say
that VS 2005 is unsupported by Emacs 22.1.

I can post the patches I needed to get Emacs to compile with VS 2005,
if someone wants to work on this.

Btw, the bare-bones download of VS 2005 couldn't even begin compiling
the test programs during `configure', since there's no windows.h
header file.  I needed to force VS 2005 to use the Platform SDK
include directory, to get it to compile.  Maybe that's one reason
Emacs crashed, but then how to get the missing headers?

Re: Compilation problems with latest MSVC

[Jason Rumney]

Eli Zaretskii wrote:
> I can post the patches I needed to get Emacs to compile with VS 2005,
> if someone wants to work on this.
>   

I think I've figured out most of them, the remaining problem I'm having 
is that strftime.c and editfns.c want to use _tzname, which is not 
defined by any of the libraries.

The changes I had to make outside the makefiles seem harmless, so I've 
checked them in.

Re: Compilation problems with latest MSVC

[Eli Zaretskii]

> Date: Fri, 29 Dec 2006 16:25:03 +0000
> From: Jason Rumney <jasonr@gnu.org>
> Cc: David Robinow <drobinow@gmail.com>, emacs-devel@gnu.org
> 
> I think I've figured out most of them, the remaining problem I'm having 
> is that strftime.c and editfns.c want to use _tzname, which is not 
> defined by any of the libraries.

I think I solved that by having HAVE_TZNAME defined in src/s/ms-w32.h
only for versions of MSVC before 1400.  If you think this is an okay
solution, I can dig out the patches (not that the above leaves any
place for doubt about the exact change).

> The changes I had to make outside the makefiles seem harmless, so I've 
> checked them in.

Thanks.

How did you solve the problem with missing headers (windows.h and
probably the rest of Windows-specific ones)?

Re: Compilation problems with latest MSVC

[Jason Rumney]

Eli Zaretskii wrote:
> How did you solve the problem with missing headers (windows.h and
> probably the rest of Windows-specific ones)?
>   
I'm not using the no-cost version, so everything comes prepackaged. From 
when I used the no-cost version in the past, there were several separate 
downloads needed, and figuring out which ones and how to configure the 
paths so the compiler can find everything was not an easy task, and 
completely undocumented. It sounds like you are missing the Win32 
Platform SDK.

Re: Compilation problems with latest MSVC

[Eli Zaretskii]

> Date: Fri, 29 Dec 2006 23:05:54 +0000
> From: Jason Rumney <jasonr@gnu.org>
> Cc: drobinow@gmail.com, emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> > How did you solve the problem with missing headers (windows.h and
> > probably the rest of Windows-specific ones)?
> >   
> I'm not using the no-cost version, so everything comes prepackaged. From 
> when I used the no-cost version in the past, there were several separate 
> downloads needed, and figuring out which ones and how to configure the 
> paths so the compiler can find everything was not an easy task, and 
> completely undocumented. It sounds like you are missing the Win32 
> Platform SDK.

No, I did install the Platform SDK (and tweaked the VS 2005 startup
script to invoke the SDK startup script, to set up INCLUDE and LIB
paths correctly).  But I wasn't sure about the correct order of the
paths (since there could be duplicate libraries/headers).  Also, the
Platform SDK had several versions since VS 2005 was released, and I
wasn't sure the last one that's available is compatible with VS 2005.

But since you've got the same crash with your prepackaged version, I
think my fears were unsubstantiated, and the crash is a real problem.

Re: Compilation problems with latest MSVC

[Jason Rumney]

Eli Zaretskii wrote:
> I think I solved that by having HAVE_TZNAME defined in src/s/ms-w32.h
> only for versions of MSVC before 1400.  If you think this is an okay
> solution, I can dig out the patches (not that the above leaves any
> place for doubt about the exact change).
>   

That was enough to get to the crash while dumping, but since tzname is 
in the system headers, I think it is possible to find a better solution 
if we can make it work.

The crash is happening within the initialization code before any Emacs 
code gets run (__tmainCRTStartup). This code is calling _free_internal, 
which we are redefining in gmalloc.c. I'm not sure if this can be fixed 
without some major changes, so I'm inclined to put it aside until after 
the release.

Re: Compilation problems with latest MSVC

[Eli Zaretskii]

> Date: Fri, 29 Dec 2006 23:43:17 +0000
> From: Jason Rumney <jasonr@gnu.org>
> Cc: drobinow@gmail.com, emacs-devel@gnu.org
> 
> The crash is happening within the initialization code before any Emacs 
> code gets run (__tmainCRTStartup). This code is calling _free_internal, 
> which we are redefining in gmalloc.c.

That rings a bell: during linking, the linker complained about
multiple definitions of some memory-related functions, I think calloc
and realloc.  Did you have those warnings in your build?

Re: Compilation problems with latest MSVC

[Jason Rumney]

Eli Zaretskii wrote:
>> Date: Fri, 29 Dec 2006 23:43:17 +0000
>> From: Jason Rumney <jasonr@gnu.org>
>> Cc: drobinow@gmail.com, emacs-devel@gnu.org
>>
>> The crash is happening within the initialization code before any Emacs 
>> code gets run (__tmainCRTStartup). This code is calling _free_internal, 
>> which we are redefining in gmalloc.c.
>>     
>
> That rings a bell: during linking, the linker complained about
> multiple definitions of some memory-related functions, I think calloc
> and realloc.  Did you have those warnings in your build?
>   
Yes, they appear as errors if you link against libcmt.lib, unless you 
include -force:multiple in LINK_FLAGS. I suspect that the single 
threaded library is required for Emacs, as the multithreaded library 
will be allocating heap memory for each thread behind your back to avoid 
problems with global variables, so there will always be a conflict 
between Emacs's and the C library's malloc routines.

I also tried linking against msvcrt.lib (the dynamic linked version of 
libcmt). It doesn't complain about the multiple definitions, but there 
are more unresolved symbols. I also recall Andrew Innes trying in the 
past to get Emacs working with the dynamic linked c runtime, I'm not 
sure if he succeeded in the end by ensuring that Emacs's memory 
allocations do not intertwine with the system library's or whether he 
gave up.

Re: Compilation problems with latest MSVC

[Eli Zaretskii]

> Date: Sun, 31 Dec 2006 00:13:18 +0000
> From: Jason Rumney <jasonr@gnu.org>
> Cc: drobinow@gmail.com, emacs-devel@gnu.org
> >
> I suspect that the single threaded library is required for Emacs, as
> the multithreaded library will be allocating heap memory for each
> thread behind your back to avoid problems with global variables, so
> there will always be a conflict between Emacs's and the C library's
> malloc routines.

Alas, there's no single-threaded library that comes with VS 2005: they
removed it.  The docs says "use the multithreaded library instead".
So it sounds like all later versions of MSVC will have this problem.

Re: Compilation problems with latest MSVC

[Jason Rumney]

David Robinow wrote:
>  There is a warning that debugtype:both is no longer supported.  I
> don't remember which type it actually uses.  As shown below, this
> warning became an error in Visual Studio 2005.
I think it is OK to remove this option. It was useful when Emacs could 
not be compiled with gcc on Windows, because it allowed people to debug 
the precompiled binaries using gdb. But now that gcc is used to build 
the precompiled binaries, we can assume that anyone compiling with msvc 
will also have access to the microsoft debugger.