I don't know much about ELF internals, but stepping through the processing code in the debugger I see an obvious bug: the bit that finds the total code size only winds up using the last segment, then the later code always uses the first segment. For whatever reason your pdex.elf has three segments: text and code in the first, bss in the second, and then.. bss also in the third but the type is GNU_STACK? I don't know what that's about, but bss doesn't take up space in the file so the compiler marks the total data size as zero, then it doesn't copy anything to the code buffer and then the compression function complains that it doesn't have anything to compress. It looks like our C API examples wind up with just one segment containing text, data, and bss, so I'd guess that's what Marc was testing against when he wrote that code and he didn't hit that bug.
I changed that first size checking loop to break when it sees a segment with non-zero code size and note which segment that is so it can copy its code later on. I'm assuming here you'd only ever have one segment with code+text? Here's a macOS build with that change. Not sure though what all you'll have to do to convince the OS that yes you really want to run this random binary you downloaded..
pdc.zip (793.4 KB)