To my knowledge, there is no relationship between Forks, and Thread or threads other than that Forks attempts to emulate the threads interface using fork'd processes instead of threads.

And going by your demonstration of the failure, the problem appears to clearly lie entirely within, or as a side effect of using the Forks module, and I see no way that re-building perl would have any effect whatsoever.

Out of curiosity I went to cpan to look up the current maintenance status of the module and whilst browsing around, discovered this snippet in the POD:

Modules that modify $SIG{CHLD}

In order to be compatible with perl's core system() function on all platforms, extra care has gone into implementing a smarter $SIG{CHLD} in forks.pm. If any modules you use modify $SIG{CHLD} (or if you attempt to modify it yourself), you may end up with undesired issues such as unreaped processes or a system() function that returns -1 instead of the correct exit value. See perlipc for more information regarding common issues with modifying $SIG{CHLD}.

Which sounds an aweful lot like the problem you are experiencing, albeit that you are not modifying %SIG. If you are set on continuing to use Forks, then it might be as well to contact the new maintainer.

Alternatively, if you just need to run a ping asynchrounously, using threads:

use threads;
use threads::shared;

my $pingStatus : shared = undef;
async{ 
    $pingStatus = system 'ping', ...;
};

.... do other stuff

if( $pingStatus == ? ) {
   ## ....
}
[download]

Or, even simpler, especially if you need to ping multiple targets concurrently, use Net::Ping in 'syn' mode, which is far more efficient than any other method.