Obviously, it also helps to know a bit of C to successfully install modules that fail make. I don't know much C, but the stuff that will most likely bite you when installing/compiling C extensions are platform / header file differences.

My approach to hacking at a C extension is, that the C code in principle works and that the included Perl tests exercise the extension behaviour good enough to uncover most things I break when dabbling.

Things that I did to get stuff to compile :

• #define long int - in HTML::Tidy, I had to make VC6 believe through the preprocessor that an int and a long were the same thing (which, on a 32bit machine, they are) to get it to compile. The error message said something like need explicit cast from int to long, but I didn't want to modify anything in the actual C code.
• Replaced a #define define INTPTR_TYPE long long by # define INTPTR_TYPE __int64 . This was prompted by the VC error error C2632: 'long' followed by 'long' is illegal, as long long is a gcc extension AFAIK.

So don't be afraid to change bits in the C header files to adjust the C code to what you think your machine actually is, but do pass these changes upstream to the module author - the next release might have your change already built in - and also be prepared for bugs in your modified versions - keep track of what you changed and which extensions you compiled yourself.

perl -MHTTP::Daemon -MHTTP::Response -MLWP::Simple -e ' ;    # The  
$d = new HTTP::Daemon and fork and getprint $d->url and exit;#spider
($c = $d->accept())->get_request(); $c->send_response( new   #in the
HTTP::Response(200,$_,$_,qq(Just another Perl hacker\n))); ' #  web 
[download]