Just like appl/simple/client/sim_client.c in krb5 itself, perl-Authen-Krb5 uses internal APIs (krb5_gen_portaddr, krb5_gen_replay_name, krb5_free_enc_tkt_part) in its example code. These functions also have been added to the XS module. As these functions are internal, it's not really possible to call them outside krb5. There's no function prototype in the installed header files. I asked for advice on the kerberos list: appl/simple/client/sim_client.c uses internal APIs <https://mailman.mit.edu/pipermail/kerberos/2023-February/022905.html>
This now has been resolved on the krb5 side. The internal function calls are not really required given the example has been written. Unfortunately calls to krb5_free_enc_tkt_part and krb5_free_address remain. I think both calls appear in contexts that are bit dubious, and crashes are only avoided due to memory leaks. When an Authen::Krb5::EncTktPart object is returned from Authen::Krb5::Ticket::enc_part2, it would actually be required that this object retains a reference to the original Authen::Krb5::Ticket object. Instead it creates a new object with its own reference counter, and then papers over some adverse effect with that krb5_free_enc_tkt_part call in Authen::Krb5::EncTktPart::DESTROY. The DESTROY method for Authen::Krb5::Address calls krb5_free_address. This calls C free on the contents member, but that contents member is set to a SvPV-allocated pointer in Authen::Krb5::Address::new. I guess we have to build this in C89 mode to make these undeclared function calls valid for now. I'll report these issues upstream as well.
Uh-oh. Upstream basically closed down in January. <https://metacpan.org/dist/Authen-Krb5> links to <https://github.com/sophos/p5-Krb5/commits/master>, which is archived. It probably does not make sense to report this to <https://rt.cpan.org/Public/Dist/Display.html?Name=Authen-Krb5>, given that this leads reporters to the archived Github repository, too.