Somewhat recently, I tried to use pdisk ( from /usr/src/dist/pdisk ) on 
a i386 with
a mac drive with an apple map.  So I built it, it compiled ok, but it 
complained that
there was no valid pmap etc, well there was,  I figured it was a byte 
order problem, and
it turned it it was.  Basically, it only does the right thing on linux, 
else it falls
through, and hard codes some stuff as if on a system w/o endian.h, ( 
maybe MACOS8,9, etc?)
It's all in convert.c, 
http://cvsweb.netbsd.org/bsdweb.cgi/src/dist/pdisk/convert.c

It's simple to add it, 2 lines, which I did, and it seems that simple.
#diff convert.c.~1~ convert.c
31a32,33
 > #elif defined( __NetBSD__)
 > #include <sys/endian.h>

I was able to read my org. imac hd's  partition map , on my pc, I also 
compiled and tested on my imac both in netbsd, and OSX, where it still 
worked,  though if OSX was intel, it wouldn't ;-].  As far a write 
test, I used it on my pc, to initialize a 149 GB disk, then stuck
it a firewire enclosure and read it on the mac, there I hit a 128 GB 
28bit addressing issue,
so not a good test case, though apple's pdisk seemed to parse it ok.   
Maybe, I can test
with a usb pen drive I have, but I tend to think it really was that 
simple, just a matter
of it using nonportable hard coded macros where it could have using 
standard ones (which
it does on linux )

Is this worth a PR? If it's not already one?  With a working pdisk on 
i386, one could conceivably go back and forth between disklabel and 
apple's pmap,  with careful editing, allowing swapping of drives, data 
recovery etc.