Funny-business with Win32 extension module build

[Intrepid]

Under StrawberryPerl I'm having some difficulty building Win32::Exe and I'd like to get opinions from those more familiar with XS-using modules than I am.

Here's what the distribution package contains, in tree format, after I did a 'make clean'.

Win32-Exe-0.17-0/
|--Changes
|--MANIFEST
|--META.yml
|--Makefile.PL
|--Makefile.old
|--README
|--insert
|  |--InsertResourceSection.xs
|  |--Makefile.PL
|  |--Makefile.old
|  |--t
|  |  |--0-load.t
|  |  `--1-basic.t
|  `--typemap
|--lib
|  `--Win32
|     |--Exe
|     |  |--Base.pm
|     |  |--DataDirectory.pm
|     |  |--DebugDirectory.pm
|     |  |--DebugTable.pm
|     |  |--IconFile.pm
|     |  |--InsertResourceSection.pm
|     |  |--Manifest
|     |  |  `--Parser.pm
|     |  |--Manifest.pm
|     |  |--PE
|     |  |  |--Header
|     |  |  |  |--PE32.pm
|     |  |  |  `--PE32Plus.pm
|     |  |  `--Header.pm
|     |  |--PE.pm
|     |  |--Resource
|     |  |  |--GroupIcon.pm
|     |  |  |--Icon.pm
|     |  |  |--Manifest.pm
|     |  |  `--Version.pm
|     |  |--Resource.pm
|     |  |--ResourceData.pm
|     |  |--ResourceEntry
|     |  |  |--Id.pm
|     |  |  `--Name.pm
|     |  |--ResourceEntry.pm
|     |  |--ResourceTable.pm
|     |  |--Section
|     |  |  |--Code.pm
|     |  |  |--Data.pm
|     |  |  |--Debug.pm
|     |  |  |--Exports.pm
|     |  |  |--Imports.pm
|     |  |  `--Resources.pm
|     |  `--Section.pm
|     `--Exe.pm
|--script
|  `--exe_update.pl
`--t
   |--0-pod.t
   |--1-basic.t
   |--2-icon.t
   |--3-manifest.t
   |--4-execupdate.t
   |--application.xml
   |--empty.xml
   |--hd.ico
   |--par.ico
   |--winexe32.exe
   `--winexe64.exe

The error in the make step is this:

gcc -c -std=c99 -DWIN32 -DWIN64 -DPERL_TEXTMODE_SCRIPTS -DMULTIPLICITY
+ -DPERL_IMPLICIT_SYS -DUSE_PERLIO -D__USE_MINGW_ANSI_STDIO -fwrapv -f
+no-strict-aliasing -mms-bit fields -O2 -DVERSION=\"0.17\" -DXS_VERSIO
+N=\"0.17\" "-ID:\SBP\perl\lib\CORE" InsertResourceSection.c
gcc: fatal error: no input files
compilation terminated.

I'm trying not to post too much from the screen so I'll just show this context for the error:

Running Mkbootstrap for InsertResourceSection ()
"D:\SBP\perl\bin\perl.exe" -MExtUtils::Command -e chmod -- 644 "Insert
+ResourceSection.bs"
"D:\SBP\perl\bin\perl.exe" -MExtUtils::Command::MM -e cp_nonempty -- I
+nsertResourceSection.bs ..\blib\arch\auto\Win32\Exe\InsertResourceSec
+tion\InsertResourceSection.bs 644
"D:\SBP\perl\bin\perl.exe" "D:\SBP\perl\lib\ExtUtils/xsubpp"  -typemap
+ D:\SBP\perl\lib\ExtUtils\typemap -typemap C:\Users\somia\build\straw
+berry-perl\Win32-Exe-0.17-0\insert\typemap InsertResourceSection.xs >
+ InsertResourceSection.xsc
"D:\SBP\perl\bin\perl.exe" -MExtUtils::Command -e mv -- InsertResource
+Section.xsc InsertResourceSection.c

So the obvious thing to do is to look at the file tree for InsertResourceSection.c and it's at Win32-Exe-0.17-0/insert/InsertResourceSection.c. That's why I say there's "Funny business." ;-(

Jun 04, 2025 at 21:09 UTC

[pryrt]

Given It's Tuesday, so it must be the day for Trouble With Cpan, I am not convinced you have your Strawberry Perl build environment setup correctly yet with the standard cpan client. When you say you ran the make step, to be clear, did you mean you used some other make like the cygwin make in the other conversation, or are you 100% certain you are using the gmake from Strawberry Perl?

Instead of using the standard client, with Strawberry, I've always used cpanm , because it's always "just worked" for me -- the builds are reliable, and there are no extra steps needed.

To give more details, I will use the cpanm-enabled version of the "standard incantation":

cpanm --look Win32::Exe
perl Makefile.PL
gmake
gmake test

The --look puts me into the download-and-build directory, so I can manually run the other steps. Otherwise, cpanm Win32::Exe would have just built and installed the module for me, without any difficulty, and without having to remember which make/dmake/gmake to use (there was some confusion briefly when Strawberry switched from dmake to gmake, but it's been highly consistent since then, and I doubt that will change again anytime soon), or any such thing.

That incantation builds and tests just fine for me, as seen in the spoiler below. Since you chose not to share the other information from your build, which may have given more clues as to your problem, I will just say "make sure your build environment is right and you are using the right executables; especially check to make sure that you are running the Strawberry Perl versions of various executables rather than something in your cygwin setup; where cpan and where cpanm and where gmake and the like are your friend."

<Reveal this spoiler or all in this thread>

[Intrepid]

pryrt wrote:

Given It's Tuesday, so it must be the day for Trouble With Cpan, I am not convinced you have your Strawberry Perl build environment setup correctly yet with the standard cpan client. When you say you ran the make step, to be clear, did you mean you used some other make like the cygwin make in the other conversation, or are you 100% certain you are using the gmake from Strawberry Perl? Instead of using the standard client, with Strawberry, I've always used cpanm , because it's always "just worked" for me -- the builds are reliable, and there are no extra steps needed.

I can assure you all that I have the right 'make' now, after the debacle with "It's Tuesday, ..." ;-). When I said the make step I was speaking generically, what I actually typed was gmake. And I went through my Config.pm for CPAN to see that the options were set right for portable Strawberry v5.40.2 on my USB drive.

But your instincts were working fine. I ignored the .bat file that comes with portable Strawberry after taking a brief glance at it, and what I hadn't fixed was $PATH. I was working in a cygwin bash shell in a terminal emulator instead of being dropped into a CMD shell, with appropriate shell variables set, by the bat file. Long story shortened: that was cygwin's gcc running into trouble, not Strawberry's.

Your reply really helped me out and I successfully built Win32::Exe, 100% tests ok, and I think I am going to be having some clear sailing now (at least until the next time I do something foolish).

Jun 05, 2025 at 00:56 UTC