|There's more than one way to do things|
Actually now that I re-read the description of your problem I have to conclude it probably has nothing at all to do with Inline::C. The second test is comparing the results of the pure Perl sub to the results of the sub that invokes an external program. That external program is the C++ program whos source I provided in my example.
That program is not seen or touched by Inline::C. Inline::C doesn't know or care about it.
The C++ program has to be saved in its own C++ source file, compiled, and linked to a filename that makes sense for your operating system. In fact whether it's Win32 or Linux, there's no harm in having an .exe suffix in this simple test case. Just compile the C++ source into an executable named 'primes.exe', and put it wherever the script will be able to find it (or specify a fully qualified path within the Perl script's call to primes.exe).
Maybe you've already done all this. If you haven't, go ahead and do it now.
The next step in sleuthing what's going wrong would be to invoke primes.exe (the executable built from the C++ source I provided). Invoke it with some smallish integer, like primes.exe 100. Then try it as primes.exe 100000, and again as primes.exe 1000000.
If it runs properly in all those cases, there's no sane reason it shouldn't work from within your Perl script. If it doesn't run properly, perhaps you have a C++ compiler and library that lacks the Standard Template Library, which is a necessary component of the C++ program.
If all else fails, you ought to be able to just remove the 2nd test, and remove all mention of the external_cpp() sub within the Perl script (remove the function's declaration/definition, and its use within the cmpthese() benchmark). Then you'll only be comparing the Inline::C function with the pure Perl one; you're taking the C++ program out of the equation.
Hope this helps...