See perlguts.pod for more details about the [adp]THX_? macros, but basically, you're using a perl compiled for multiplicility/threading, and in those perls, most perl functions (including SvPV()) expect to take an extra first argument, called my_perl, which is a pointer to the current perl interpreter.

The idea is that on threaded perls, these macros typically expand as follows:

aTHX   my_perl
aTHX_  my_perl,
pTHX   PerlInterpreter* my_perl
pTHX_  PerlInterpreter* my_perl,
dTHX   PerlInterpreter* my_perl =
           something_that_retrieves_the_current_perl();
[download]

while on unthreaded perls they expand to null strings.

You typically declare any function as expecting an interpreter as the first arg:

void foo(pTHX_ SV * sv) { ... }
[download]

and invoke it as

foo(aTHX_ some_sv);
[download]

Normally your XS sub will have been passed a my_perl arg, and you can pass this on down the chain of called subs using aTHX/pTHX. In those cases where this isn't possible, dTHX can be used within the declaration section of a function to recreate my_perl 'on the fly', but it's expensive:

void foo(SV * sv) {
    dTHX;
    ...
}
[download]

All the above assumes that PERL_NO_GET_CONTEXT is defined in your source. If it isn't then aTHX is redefined to directly compute the interpreter address, like dTHX. This means everything 'just works' without messing with aTHX/pTHX, but is slow. Since you were getting compilation errors about missing my_perl, I'm assuming you must have had PERL_NO_GET_CONTEXT defined.

Dave