I'm mainly writing this in hopes that it gets picked up by Google in
case anyone else runs into this problem.
I was going to distribute the source & binaries for the first sneaky-
peek at Swfdec for Mac OS X today. But yesterday, when I tried running
my player application within Mac OS X's PowerPC emulator (Rosetta), I
noticed it was crashing in some animations with the following stderr
output:
GThread-ERROR **: file gthread-posix.c: line 197
(g_mutex_trylock_posix_impl): error 'Invalid argument' during
'pthread_mutex_trylock'
Of course, this wasn't happening in the Intel build, only PPC. And I
can't ship a binary that's going to be unstable on many users'
computers. So I searched Google and found several other people who had
run into this problem, but no one had a solution.
Then I remembered that glib writes out one very CPU-specific header
file, glibconfig.h, that includes everything from byte-swapping macros
to the structure of a pthread mutex. I knew from previous experience
that the file was very different when building for X86-64 than it was
on X86, but then I forgot that it was probably different between X86
and PPC as well.
One of the more interesting features of Mac OS X's Mach-O ABI is the
ability to include code for multiple architectures in a single
executable. But the GNU build system was set up under the assumption
that nobody ever did this, which was probably a safe assumption to
make in the early '90s, but is kind of dated now. Nevertheless, I was
building glib by setting multiple architectures in CFLAGS and
disabling autoconf dependencies, trying to weasel around this
restriction, which resulted in a glibconfig.h file with a little-
endian mutex format, which is what was causing the crash.
So I had to build glib manually three times, once for PPC, once for
X86, and once for X86-64, and then manually mash the glibconfig.h and
binaries together. Which is incredibly tedious, since it can't be
automated (at least, not the glibconfig.h part). I didn't even bother
with a PPC64 build. But once I did this, then the player quit
crashing, and world peace was realized.
If you're reading this through Google, I hope this helped you...
Oh, yes, and I'll now release the source & binaries next Monday during
prime-time. Maybe now I'll have some time to figure out how to decode
video with ffmpeg directly...
Nick Zitzmann
<http://seiryu.home.comcast.net/>
S/MIME signature available upon request
