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
|Replies are listed 'Best First'.|
Re^2: A Practical Guide to Compiling C based Modules under ActiveState using Microsoft C++
by JRHeisey (Initiate) on Oct 22, 2015 at 17:20 UTC