The problem is that the file: detector.xs is being compiled as C, but it contains C++ extensions:

extern "C" {
[download]

The file compiles clean (with a couple of trivial warnings), if you add option -TP to cause the compiler to treat the file as C++.

Unfortunately, as with all these build mechanisms, the process is so stupidly convoluted that working out how to add a simple compiler option is your typical OO maze of dark, twisty packages.

The way I tested it was:

1. start the compile (using command nmake) at the command line and the immediately pause it using ^S.
2. Switch to another session, and make a copy of the file under a different name: Encode-Detect-1.01\lib\Encode\Detect\Detector.ccs.

   This is a compiler "options response file" that is generated automatically, but then deleted.

3. Switch back to the first session and hit any key allowing the compile to continue to failure.
4. Edit the file you saved and add -TP as a new last line.
5. Rename the file back to Encode-Detect-1.01\lib\Encode\Detect\Detector.ccs
6. Switch back to the first session, and C&P the last compiler command issued by the nmake. It should look something like this:

   C:\Perl64\packages\Encode-Detect-1.01>cl -nologo -c @"lib\Encode\Detec
   +t\Detector.ccs" -Fo"lib\Encode\Detect\Detector.obj" "lib\Encode\Detec
   +t\Detector.c"
   Detector.c
   lib\Encode\Detect\Detector.xs(79) : warning C4267: 'argument' : conver
   +sion from 'size_t' to 'PRUint32', possible loss of data
   lib\Encode\Detect\Detector.xs(109) : warning C4267: 'argument' : conve
   +rsion from 'size_t' to 'PRUint32', possible loss of data
   [download]

At that point, reissuing the nmake ought to allow things to complete--but it doesn't:

C:\Perl64\packages\Encode-Detect-1.01>nmake

Microsoft (R) Program Maintenance Utility Version 9.00.21022.08
Copyright (C) Microsoft Corporation.  All rights reserved.

        C:\Perl64\bin\perl.exe Build --makefile_env_macros 1
ExtUtils::Mkbootstrap::Mkbootstrap('blib\arch\auto\Encode\Detect\Detec
+tor\Detector.bs')
Generating script 'lib\Encode\Detect\Detect.lds'
link @"lib\Encode\Detect\Detect.lds" -out:"blib\arch\auto\Encode\Detec
+t\Detector\Detector.dll"
LINK : warning LNK4044: unrecognized option '/lstdc++'; ignored
Detect.def : error LNK2001: unresolved external symbol boot_Encode__De
+tect
Detect.def : error LNK2001: unresolved external symbol boot_Encode__De
+tect
lib\Encode\Detect\Detect.lib : fatal error LNK1120: 2 unresolved exter
+nals
mt -nologo -manifest "lib\Encode\Detect\Detect.dll.manifest" -outputre
+source:"blib\arch\auto\Encode\Detect\Detector\Detector.dll";2

lib\Encode\Detect\Detect.dll.manifest : general error c1010070: Failed
+ to load and parse the manifest. The system cannot find the file spec
+ified.
Manifying blib\lib/Encode/Detect.pm -> blib\libdoc\Encode.Detect.3
Manifying blib\lib/Encode/Detect/Detector.pm -> blib\libdoc\Encode.Det
+ect.Detector.3
HTMLifying blib\lib\Encode\Detect.pm -> blib\libhtml\site\lib\Encode\D
+etect.html
Build: blib\lib\Encode\Detect.pm: cannot resolve L<Encode> in paragrap
+h 18.
HTMLifying blib\lib\Encode\Detect\Detector.pm -> blib\libhtml\site\lib
+\Encode\Detect\Detector.html
[download]

And I haven't been able to hack my way past that one because again, the autogenerate linker response file: lib\Encode\Detect\Detect.lds is deleted automatically (why?), and it happens too fast for me to be able to intervene.

So, your only choice is to try and navigate that purile maze of OO dark, twisty packages to try and work out what is generated inside that file. If you succeed in doing that, then you might stand some chance of working out why it is wrong.

Or you can throw the problem back at the authors of the module and the build process and wait until they decide who is in the wrong and put it right. Say, 3 years from now if you are lucky!