1) Can't the PL file that generates the module place it in blib (creating the 'blib' directory if it's not already existent)?

I tried that. The PL files (which I call build_my_module.PL from now on) is executed after the pm_to_files phase. I was able to open the related PM files, append information to it and close it, but this was too late since a copy (without the parts I need) was already put on 'blib'. I can write over there too, just will need to set right permissions, write, set read-only permissions again. But looks like a hack after all. I didn't get what the documentation says about "PL output is suppose to be used to the given parameter". Printing the output to STDOUT doesn't produce the expected results, and looking at the Makefile (which calls the script with a perl build_my_module.PL, returning data wouldn't do either. I'm explicit using open for that.

2) If the C header files are not found by default, then surely it's up to the user to make them locatable - eg by setting the relevant environment variable, or providing INC arg to Makefile.PL.

There is a long discussion about this on the CPAN Testers mailing list, but from it I have the following conclusions:

1. These constants will change depending on processor architecture
2. Best way to achieve the right header file is using the C compiler itself, since h2ph doesn't quite work (at least not in Ubuntu). So, to make it clear, I don't need the C compiler really, but I need it to grab me the correct constant value to use with syscall.

Another possibility is to create a hash with the keys being the architecture and the values the related constants, but this is a hack and there is no telling when it is going to be broken.