(bcc'ing again...) On Fri, Mar 2, 2012 at 1:28 PM, Jim Washington <[email protected]> wrote:
> Todd Whiteman, from (probably) ActiveState, seems to be doing > maintenance on pyxpcom. yes he is. the problem that todd (and us) have is that releases of pyxpcom are critically dependent on the codepaths used by pyxpcom - but not used by anything else - actually working. (and hulahop even more so because it uses XRE_InitEmbedding2, which the pyxpcomext plugin does not afaiui) here's a summary of the history of the various releases of xulrunner. bear in mind throughout all of this that hulahop is *stable* code, has had and requires absolutely no "development" whatsoever, and works perfectly. * 1.9.1 - pyxpcom and hulahop worked perfectly. activestate did a "stand-alone" release of komodo. * 1.9.2 - critical and necessary changes to XPCOM stopped pyxpcom from compiling. * 2, 3, 4, 5, 6 - todd didn't have time to fix things * 7 - todd got everything sorted, did a "stand-alone" release of komodo. activestate now happy. * 9 - i compiled pyxpcom and hulahop - success! * 10 - debian's mozilla maintainer pointed out that xulrunner 9 is too old: i try compiling 10 and... it segfaults. something related to Window Set Focus management. * 11 - i can't even get this to compile because of missing files (Proxy Object Manager) that appear not to have been correctly removed from the mozilla-central codebase * 12 - i can compile this but at runtime there's an error about a missing function in libnss3. this turns out to be because the mozilla developers in their infinite wisdom used a version of libnss3 that was never actually released, and they use *internal* header files to refer to a function that never made it into the publicly-released library * 13 - another segfault. this time the stack trace goes back to the startup function, XRE_InitEmbedding2! it's related to security settings, but that's about the limit of my expertise, time and patience to investigate, after trying to do binary search through the mozilla codebase. this graphically illustrates why i am advocating to the mozilla foundation that they bring pyxpcom (and hulahop) into the mozilla-central codebase. i've gone up and down the mozilla-central commits and i simply can't find even a starting point that actually works in order to _begin_ a binary search, in order to find out what the bloody problem is! otherwise i would be able to say "ah ha - this commit broke things". i'm going to have another go at it, but... yeah. l.
