5.36.0 and VS2022 compile errors

[rosshgit]

Module: Core from source

Errors in compiling with 5.36.0 in MS VS 2022.

In 32bit mode (WIN64= undef).

One of the compiling steps shows:

..\util.c(2624): error C2059: syntax error: 'do'
..\util.c(2624): error C2059: syntax error: 'while'
..\util.c(2625): error C2371: 'Perl_safesysfree': redefinition; different basic types
..\util.c(358): note: see declaration of 'Perl_safesysfree'
..\util.c(2626): error C2059: syntax error: '}'
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.33.31629\bin\HostX86\x86\cl.EXE"' : return code '0x2'

Sorry - too many ifdef's in this area for me to work out the error.

[twata1]

For your information, in my case, I have been able to compile on Windows 8.1 using the following procedure.

(Note: If using 7-zip for extraction.)

1. Create C:\VCPerl32 folder.
2. Download perl-5.36.0.tar.gz from metacpan (https://cpan.metacpan.org/authors/id/R/RJ/RJBS/perl-5.36.0.tar.gz) and put it into C:\VCPerl32 folder.
3. Select perl-5.36.0.tar.gz and press right-click.
4. On the new small menu window that appears, select "7-zip" and choose "Extract Here".
   (perl-5.36.0.tar should appear in the same folder.)
5. Select perl-5.36.0.tar and press right-click.
6. On the new small menu window that appears, select "7-zip" and choose "Extract Here".
7. Open C:\VCPerl32\perl-5.36.0\win32\Makefile in any editor and edit as follows:

[...]

# Visual C++ 2022 (aka Visual C++ 14.3) (full version or Community Edition)
CCTYPE		= MSVC143

[...]

INST_TOP	= $(INST_DRV)\VCPerl32

[...]

WIN64		= undef

[...]

INST_VER	= \5.36.0

[...]

USE_64_BIT_INT	= define

Launch "x86 Native Tools Command Prompt for VS 2022" from the Start menu.

On that Command Prompt, run the following.

cd C:\VCPerl32\perl-5.36.0\win32
nmake

I hope I can be of help.

[sisyphus]

Like @twata, I've struck no issue with VS 2022 when building a 32-bit perl-5.36.0.
Unlike @twata, I'm on Windows 11.

My approach was to set up the 32-bit environment by executing:

C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvars32.bat

I then built, tested and installed perl-5.36.0 by running:
nmake INST_TOP=D:\perl-5.36.0-vs-32 CCTYPE=MSVC143 WIN64=undef test
then
nmake INST_TOP=D:\perl-5.36.0-vs-32 CCTYPE=MSVC143 WIN64=undef install

Everything worked fine.

The compilation of util.c proceeded without any issues:

 cl -c -I.. -nologo -GF -W3 -MD -I..\lib\CORE -I.\include -I. -I.. -DWIN32 -D_CONSOLE -DNO_STRICT -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -D_WINSOCK_DEPRECATED_NO_WARNINGS -DPERLDLL -DPERL_CORE   -O1 -Zi -GL  -DPERL_TEXTMODE_SCRIPTS -DMULTIPLICITY -DPERL_IMPLICIT_SYS -Fo..\util.obj ..\util.c
util.c

@rosshgit, is that identical to the command that was run on your build ?
What version of WIndows are you running ?
Did you specify the correct setting for CCTYPE ? (ie CCTYPE=MSVC143)

Cheers,
Rob

[rosshgit]

Looking deeper into this, the fault appears after the command:

nmake clean

Using any of the examples above:

nmake INST_TOP=D:\perl-5.36.0-vs-32 CCTYPE=MSVC143 WIN64=undef
nmake clean
nmake INST_TOP=D:\perl-5.36.0-vs-32 CCTYPE=MSVC143 WIN64=undef
...kaboom.

This tested and applies to both the 5.36.0 gzip source file, and the latest (5.37.5) repository code base. It was present in 5.34 as well, but 5.32 seemed OK.

There is also makefile commands "distclean" which works and code can be compiled again. And command "realclean" which is not clean enough to compile.

Something in the clean command on MSVC makefile build, is not doing enough deleting to get back to an original state, and leaves the code base broken.

[sisyphus]

I don't know how much should be removed by nmake clean.
I've always assumed it was quite acceptable for 'clean' to leave some stuff behind and that you should call 'distclean' if you want the perl source to be returned to its original state.

If I run nmake clean and follow that up with nmake distclean then I can see that 'distclean' removes .pdb and .lib (and other) files that 'clean' did not.
I also see that 'distclean' removes the utils/Makefile that 'clean' left in place, which seems a bit ominous :

        del /s ..\utils\Makefile
Deleted file - D:\comp-2022-vs-32\perl-5.36.0\utils\Makefile

I would recommend that you just use 'distclean', and not worry about what 'clean' does and doesn't do.
But if you think there's something here that ought to be fixed, then hopefully someone will be able to help out.

Cheers,
Rob

[jkeenan]

Looking deeper into this, the fault appears after the command:

nmake clean

Using any of the examples above:

nmake INST_TOP=D:\perl-5.36.0-vs-32 CCTYPE=MSVC143 WIN64=undef
nmake clean
nmake INST_TOP=D:\perl-5.36.0-vs-32 CCTYPE=MSVC143 WIN64=undef
...kaboom.

Looking deeper into this, the fault appears after the command:

nmake clean

Using any of the examples above:

nmake INST_TOP=D:\perl-5.36.0-vs-32 CCTYPE=MSVC143 WIN64=undef
nmake clean
nmake INST_TOP=D:\perl-5.36.0-vs-32 CCTYPE=MSVC143 WIN64=undef
...kaboom.

This tested and applies to both the 5.36.0 gzip source file, and the latest (5.37.5) repository code base. It was present in 5.34 as well, but 5.32 seemed OK.

There is also makefile commands "distclean" which works and code can be compiled again. And command "realclean" which is not clean enough to compile.

Something in the clean command on MSVC makefile build, is not doing enough deleting to get back to an original state, and leaves the code base broken.

@rosshgit, this is something we should explore, but I'm getting somewhat confused as to the specific problem you're facing. So let me ask you a diagnostic question: Using the following commands, are you able to install a working perl executable (on Windows that would presumably be perl.exe)?

$ nmake
$ nmake test
$ nmake install

If so, then your problem is not, strictly speaking, a compile error as the Subject of this ticket indicates. Your problem is that after compilation and installation you can't clean up your build directory -- in which case we would hypothesize that the Win32 Makefile has a bug or has not been kept up-to-date (the latter being quite likely, IMO).

Is the above a fair description of your problem?

Or is your problem something like this: "I get a compilation error during nmake, so I can't even get as far as nmake test or nmake install. Then when I say nmake clean I don't get a clean directory from which to start over."

[rosshgit]

If you do it all once (make, test, install), it works.

But if you want to make a configuration change, followed by a "clean", and then a second build, then its dead, and the code stays permanently dead. To recover, you have to either use a specific tailored command "distclean" (not a well known command), or delete the entire code base and unzip another code base and start over.

A "clean" command should not permanently kill the code base.

[jkeenan]

If you do it all once (make, test, install), it works.

Okay, that means we don't have a problem with perl code per se. It's a Makefile-ish problem.

But if you want to make a configuration change, followed by a "clean", and then a second build, then its dead, and the code stays permanently dead. To recover, you have to either use a specific tailored command "distclean" (not a well known command), or delete the entire code base and unzip another code base and start over.

A "clean" command should not permanently kill the code base.

Agreed. Now I have not built perl on Windows in many years and I don't have access to that platform, so I can't directly investigate your problem. But my own research suggests that on Unix this is what the various clean targets do:

make clean: Cleans up most of the build artifacts, all subsidiary Makefiles, but leaves config.sh and Policy.sh, which I think permits you to make minor changes in those files call make again without having to re-call ./Configure.

make realclean: Synonym for make clean.

make distclean: Everything done by make clean, plus config.sh, Policy.sh, t/test_state and files created as part of cross-compilation.

make veryclean: Everything above and beyond what make distclean does. I think this is equivalent to git clean -dfx (but much slower), though I haven't confirmed this.

@tonycoz, can you take a look at this ticket?