Re: MS compiler 7.1 (Visual Studio .NET 7.1 and DDK 2003) issues with make 3.80

[Eli Zaretskii]

> From: =?iso-8859-1?Q?Jerker_B=E4ck?= <address@hidden>
> Date: Fri, 22 Apr 2005 18:41:36 +0200
> Cc: address@hidden
> 
> The GNU make is a must have but there are a lot of different Win32 versions
> around. Some of them seems not to be working properly (ie. minGW, Cygwin
> 3.80 (in Mozilla FireFox)). This is not good since it will render GNU make a
> bad reputation.

Agreed.

However, my experience with GNUWin32 folks is that any bug reported to
them through their bug tracker at SourceForge gets dealt with very
quickly.  So you might consider reporting to them the bugs you found
in the MinGW version.

> So I decided to try to compile my own, which I did and it's
> working great!

That's good to hear, but it would be even better if you could run the
Make test suite and see whether all the tests pass (and debug those
which don't, if any).

> The tool I used was the Windows 2003 DDK - it's free, comes
> with complete runtime and a full optimizing compiler.

Can you post the URL of this tool suite?

> However, before I was able to compile there were some work needed to be
> done. The nmake script is not working. I found that there are several bugs
> in the configuration for the Microsoft compiler and the Microsoft runtime
> library in particular. Include files are missing and the conditional
> compilation directives (#if...#endif) are sometimes misleading.

I assume that you would like to solve these problems in the mainstream
distribution of GNU Make (because otherwise you would need to
back-port them into all future versions of Make).  If so, may I
suggest that you send a detailed report which shows every problem,
analyzes its cause(s) and discusses possible solutions, inlcuding the
one you actually used?  (It sounds like there were lots of such
problems, so perhaps subdivide your report into several ones, grouped
by similar problems/reasons.)  As Paul mentioned, the Widnows port is
maintained by a group of volunteers, and it's important that they see
the details, so that the solutions don't break other environments
where Make is built and used.

And, as Paul also pointed out, please try to build the CVS version,
and report problems and suggested changes against that version.  This
is because many problems were already fixed there, and because patches
against older versions are harder to analyze.

> Example:
> #if defined __STDC__ && __STDC__
> ...correct expression
> #else
> ...bad expression
> #endif
> 
> I assume the purpose of this is to determine the runtime library used. The
> Microsoft compiler normally sets __STDC__ to false to indicate it is using
> Microsoft extensions to ANSI C. One could of course disable the extensions
> and __STDC__ would be defined: BAD idea. I went over the code and changed
> all __STDC__ directives to something like this:
> 
> #if (defined(__STDC__) && __STDC__) || defined(_MSC_EXTENSIONS)

I'm sure this particular problem was solved more than once, including
in GNU Make, without any need to add the _MSC_EXTENSIONS condition.
Did you look at build_w32.bat, and if so, did it trigger the same
problems with the __STDC__ condition?  If not, perhaps some compiler
switches used by build_w32.bat are the solution to this problem.

Also, it seems that __STDC__ is used in Make mainly to turn on and off
the use of function prototypes.  So even if we cannot find a way to
force the MS compiler to behave the way we want, it will only miss the
additional diagnostics caused by possible mismatches in declaration vs
use of functions, which doesn't sound like a catastrophe.  (But I do
agree that it's better to find a way of using the prototypes.)

> Note: Sometimes the constant "WINDOWS32" is used in the code in same
> context. That is by my opinion not good because it could be confused with
> "WIN32" meaning "compile for windows" regardless of which runtime used.

This is deliberate: WINDOWS32 is indeed an alias for WIN32, but one
that doesn't call MS-Windows ``a win''.  The idea is that code
conditioned on WINDOWS32 is common to any Windows build/runtime
environment; code specific to certain varieties of the Windows build
should use other preprocessor macros that are specific to those
environments.  It is generally expected that the conditions specific
to some, but not all, Windows environments will be inside the
WINDOWS32 conditions.

> How I did the compile:
> 1) Find the bugs
> * set warning level 4 /W4 /WX
> * include a forced header /FI"vc_defs.h"
>   Include all needed runtime headers in vc_defs.h (stdlib.h, stdio.h etc)
> * use __stdcall calling convention  /Gz
> * add #include <direct.h> to make.h (ie line 365)
> * examine options in config.h and read readme.w32
> * compile - a lot of errors
> 
> 2) Correct
> * Disable all incorrect runtime prototypes
> * specify __cdecl for local funtions called by the runtime (ie qsort)
>   special case:  
>   typedef int (__cdecl *qsort_cmp_t) __P((void const *, void const *));
>   int (__cdecl *gl_stat) __PMT((__const char *, struct stat *));
> * optional: remove dependencies to user32.dll by change w32err.c:
>   wsprintf(szMessageBuffer, "Error %ld", ercode);     to
>   sprintf(szMessageBuffer, "Error %ld", ercode);      or 
>   _stprintf(szMessageBuffer, _T("Error %ld"), ercode);
> 
> 3) Disable warnings and build
> * link oldnames.lib

As mentioned above, please present, for each of these problems, the
full details, including the source changes you made.  It's best to
send source changes using the Diff command (you can find a port of GNU
Diffutils on the GNUWin32 site).  It is hard to comment on these
changes without knowing the details.  (Again, I assume that you'd like
to see the problems you've met solved in the future releases of Make.)

> Here is my list of warnings. Some of these may not be trivial and may
> indicate bugs 

Some of these sound like potential bugs.  I think it would be good if
you could post the actual warnings issued by the compiler, at least
for the warnings I mention below as possible bugs.  But please use the
latest sources from the CVS: there's nothing more frustrating than
wasting time on a problem that was already solved.

> #pragma warning(disable : 4018) // signed/unsigned mismatch

This warning, for instance, could be a sign of a bug...

> #pragma warning(disable : 4028) // formal parameter different from
> declaration

..and this one (if we give up this warning, why is __STDC__ an issue,
as it's only used to turn on prototypes?)

> #pragma warning(disable : 4113) // function differs in parameter lists from
> type

same here

> #pragma warning(disable : 4210) // nonstandard extension used : function
> given file scope
> #pragma warning(disable : 4213) // nonstandard extension used : cast on
> l-value
> #pragma warning(disable : 4242) // conversion to smaller type, possible loss
> of data
> #pragma warning(disable : 4244) // conversion to smaller type, possible loss
> of data
> #pragma warning(disable : 4245) // conversion, signed/unsigned mismatch

these could be bugs, it's worth exploring them one by one

> #pragma warning(disable : 4700) // local variable used without having been
> initialized
> #pragma warning(disable : 4701) // local variable may have been used without
> having been initialized

same here: possible bugs

Last, but not least: thanks for working on GNU Make.