Monday, it felt like I was spinning my wheels. I built mozilla trunk on bart, that went smoothly enough, but that was about it. Installing the XPI built on my desktop simply resulted in the console printing Failed to load render-jp2.dll — error 127. Angel refused to build the trunk, much less my extension, no matter what build configurations I tried. That was slow.
Tuesday, a breakthrough: putting $(MOZ_COMPONENT_LIBS) under EXTRA_DSO_LDOPTS meant I was using internal linkage (by linking against xpcom_core.lib), not frozen linkage! Maybe that was why it wasn’t loading? I busied myself figuring out what I could remove and what I couldn’t, but kept on running into linking issues. Unresolved symbols! PR_GetCurrentThread, PR_AtomicIncrement, PR_AtomicDecrement. After banging my head against the wall for a while and posting a query on IRC, though not in that order, a lightbulb finally turned on. I had another look at the relevant docs, and yes, that was it! I wasn’t linking against nspr4.lib, which is why all the symbols the linker couldn’t find were prefixed with PR_. Makes sense in hindsight, as things do.
Unfortunately, the net effect of this particular change was to go from “error 127″ to “error 126″. I tried looking through the source in lxr to figure out what was going on, but I hit a wall wrought from hairy platform-specific library loading calls. So, after turning to Google, I by-chance ran across a stray phrase that turned out to be just the ticket: “Try using depends.exe to figure out what dependencies your DLL has.” Another lightbulb started to glow oh-so-faintly. Subjecting render-jp2.dll to the depends.exe magnifying glass was, well, enlightening. It revealed that, duh, I’d been building a debug version of the trunk, so of course the linker was linking against the debug version of the Visual C Runtime Library (MSVCRTD), which, being not provided with the nightly builds, constituted an unresolved load-time dependency. Thus, error 126. But hey, that was steady.
After mucking about on MSDN and doing a bit of grepping through the magic that is config.mk, I saw that a combination of USE_STATIC_LIBS and MOZ_NO_DEBUG_RTL controlled the flags that direct which runtime library was to be linked against. That wasn’t quite enough, as now the linker was, by default, linking against the debug RTL, and by directive linking against the non-debug RTL. Two RTLs, two symbol definitions, one unhappy linker. So, finally, conditionally adding /NODEFAULTLIB:MSVCRTD in my Makefile was sufficient to satisfy the linker, and lo and behold, an XPI, an XPI, I do declare!
But soft! It compiles, yet will it run? A quick scp to eschew.org, a saunter upstairs, a download… and Lena, in all her DWT-encoded glory. And THAT was progress.
Now, however, I have to go eat breakfast, do errands, and drive to Newark for class. And so the adventures of yesterday must wait for tomorrow.
eschew it all 