First time here? Check out the FAQ!
THIS IS A TEST INSTANCE. Feel free to ask and answer questions, but take care to avoid triggering too many notifications.
Ask Your Question
0

Windows10 compile of WS 3.4.2 fails due to Perl modules

Hi,

I'm having a bit of difficulty compiling 3.4.2 - I've compiled 3.2.x many times without issue.

Build FAILED.

       "c:\Development\wsbuild64\Wireshark.sln" (default target) (1) ->
       "c:\Development\wsbuild64\ALL_BUILD.vcxproj.metaproj" (default target) (3) ->
       "c:\Development\wsbuild64\text2pcap.vcxproj.metaproj" (default target) (67) ->
       "c:\Development\wsbuild64\version_info.vcxproj.metaproj" (default target) (68) ->
       "c:\Development\wsbuild64\version.vcxproj.metaproj" (default target) (69) ->
       "c:\Development\wsbuild64\version.vcxproj" (default target) (77) ->
       (CustomBuild target) ->
         C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.ta
       rgets(231,5): error MSB6006: "cmd.exe" exited with code 2. [c:\Development\wsbuild64\version.vcxproj]


       "c:\Development\wsbuild64\Wireshark.sln" (default target) (1) ->
       "c:\Development\wsbuild64\doc\docs.vcxproj.metaproj" (default target) (21) ->
       "c:\Development\wsbuild64\doc\docs.vcxproj" (default target) (111) ->
         C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.ta
       rgets(231,5): error MSB6006: "cmd.exe" exited with code 2. [c:\Development\wsbuild64\doc\docs.vcxproj]

    0 Warning(s)
    2 Error(s)

Both errors relate to "missing" Perl modules:

     1>Project "c:\Development\wsbuild64\Wireshark.sln" (1) is building "c:\Development\wsbuild64\ui\qt\qtui.vcxproj.me
       taproj" (45) on node 1 (default targets).
    45>Project "c:\Development\wsbuild64\ui\qt\qtui.vcxproj.metaproj" (45) is building "c:\Development\wsbuild64\ui\qt\
       qtui.vcxproj" (117) on node 5 (default targets).
   117>InitializeBuildStatus:
         Creating "qtui.dir\RelWithDebInfo\qtui.tlog\unsuccessfulbuild" because "AlwaysCreate" was specified.
       CustomBuild:
         All outputs are up-to-date.
   111>CustomBuild:
         Can't locate Pod/Man.pm in @INC (you may need to install the Pod::Man module) (@INC contains: C \APPS\actperl\
         Perl64\lib;C \APPS\actperl\Perl64\site\lib;C \APPS\actperl\Perl64\lib\CGIC \APPS\actperl\Perl64\lib;C \APPS\ac
         tperl\Perl64\site\lib;C \APPS\actperl\Perl64\lib\CGI;C \APPS\actperl\Perl64\lib\Pod; /usr/lib/perl5/site_perl
         /usr/share/perl5/site_perl /usr/lib/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib/perl5/core_perl /u
         sr/share/perl5/core_perl) at C:/apps/actperl/Perl64/bin/pod2man line 18.
         BEGIN failed--compilation aborted at C:/apps/actperl/Perl64/bin/pod2man line 18.
   111>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targ
       ets(231,5): error MSB6006: "cmd.exe" exited with code 2. [c:\Development\wsbuild64\doc\docs.vcxproj]
   111>Done Building Project "c:\Development\wsbuild64\doc\docs.vcxproj" (default targets) -- FAILED.
    21>Done Building Project "c:\Development\wsbuild64\doc\docs.vcxproj.metaproj" (default targets) -- FAILED.

So it is complaining about this:

Can't locate Pod/Man.pm in @INC (you may need to install the Pod::Man module)

It is definitely there ... C:\apps\actperl\Perl64\lib\Pod

So I added C:\apps\actperl\Perl64\lib\Pod specifically to the PERLLIB environment variable but it still fails.

The other error was similar - it too can be found in C:\apps\actperl\Perl64\lib\Pod:

   111>CustomBuild:
         Generating AUTHORS-SHORT-FORMAT
    77>CustomBuild:
         Can't locate Pod ...
(more)
brett323's avatar
7
brett323
asked 2020-12-23 00:16:13 +0000
edit flag offensive 0 remove flag close merge delete

Comments

add a comment see more comments

1 Answer

0

Ahh, okay did more research (didn't have any luck earlier).

Reinstalled Strawberry Perl and that didn't help.

I've got Cygwin installed as well and checking my PATH, Strawberry Perl paths had been appended right at the end so it appears that, even though my PERLLIB was correct, it was actually executing Cygwin version of Perl ... thus why nothing was working.

Moving the Strawberry Perl paths right to the top meant I could now "install" the missing module ... "cpan Pod::Man" ... which worked this time, saying it was up-to-date.

But re-running cmake and build still failed ... then I noticed it was still referring to the old Perl (ActiveState).

So cleared everything, fresh source code and re-ran cmake ... this time I could see it had picked up the Strawberry Perl:

-- Found Perl: C:/Strawberry/perl/bin/perl.exe (found version "5.32.0") -- Found POD: C:/Strawberry/perl/bin/pod2man.bat

And build finally succeeded! ;)

brett323's avatar
7
brett323
answered 2020-12-23 02:50:42 +0000
edit flag offensive 0 remove flag delete link
more

Comments

I've recommended for a really long time (decades probably) that if you're building Wireshark to NOT have Cygwin on your path to prevent situations such as this occurring. If you must have Cygwin on your path for other work then you should try to isolate the Wireshark build in a separate VM.

Once CMake caches the location of a required package in CMakeCache.txt it won't look for it again, so changing the environment won't automatically fix such errors. To fix this either edit CMakeCache.txt to remove the package references or delete CMakeCache.txt to force all packages to be located again, or take the nuclear option of deleting the entire build directory.

grahamb's avatar grahamb (2020-12-23 16:07:00 +0000) edit
more
  • delete

Thanks for the info Graham, especially about forcing cmake to re-check. Yeah, I wasn't aware of that cygwin/perl issue. Up until about a week ago I never had any issue compiling 3.2.5 or 3.2.9 on my machine, which actually is a VM of my company's Win10 installation. We use an internal development tool chain for compiling SW for our products (mobile network MSS, MGW, etc.) which is where the Cygwin, git, etc. come in.

My reason for compiling WS from source is so I can compile an internal protocol dissector, and then also offer an installer that includes it as a plugin.

brett323's avatar brett323 (2020-12-23 22:21:10 +0000) edit
more
  • delete

In that VM, if it's only used for Wireshark dev, I would remove Cygwin from the path.

grahamb's avatar grahamb (2020-12-24 10:39:19 +0000) edit
more
  • delete
add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer