Bug#660487: xulrunner-dev: instant segfault in startup (related to jemalloc)

[Mike Hommey]

On Mon, Feb 20, 2012 at 01:17:49AM +0000, Luke Kenneth Casson Leighton wrote:
> On Sun, Feb 19, 2012 at 9:37 PM, Mike Hommey <mh at glandium.org> wrote:
> > On Sun, Feb 19, 2012 at 07:51:30PM +0000, Luke Kenneth Casson Leighton wrote:
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=678977#c46
> >>
> >> mike hi, it looks like this has been solved, and i leave it in your
> >> capable hands to sort out xulrunner - the question remaining is: what
> >> to do now about hulahop?  i've been asked to help get hulahop into a
> >> working state, but xulrunner 10 is so badly borked that that's
> >> impossible.
> >
> > Without specifics, there's not much I can do.
> 
>  that bugreport (#678977) contains the patches and various
> compile-time arguments that are needed to fix that _one_ bug.
> 
>  the other one is something that's still under investigation, which
> again looks to me to be memory corruption (a function which returns
> pointers to a list of windows returns a pointer with a value of
> 0x100000: it's too coincidental a value to be correct).
> 
> 
> >> that would be fine, if it wasn't for the fact that
> >> xulrunner-dev has now overwritten and replaced xulrunner-9-dev, making
> >> it impossible to now compile up python-hulahop.
> >
> > We can't indefinitely keep multiple versions of xulrunner in the
> > archive We don't scale that much.
> 
>  actually, you already have four!  xulrunner 1.9.1, 1.9.2, 9.0 and 10.0.2

1.9.1 is in lenny (oldstable), and is not supported anymore.
1.9.2 is in squeeze (stable)
9.0 happens to be in testing
10.0 is in unstable, and will replace 9.0 whenever possible.

>  but that's not the problem: the problem is generically to *all* -dev
> libraries.  hmm... let me raise this somewhere on a debian list, but
> essentially what i need to do is to create a package
> python-hulahop-that-compiles-and-links-to-xulrunner-9

And that would have absolutely no usefulness in debian

>  why?
> 
>  because of "pkg-config --variable=sdkdir libxul".
> 
>  that line says it all: where does the libxul .pc file come from?
> from the -dev package.  what that *should* be is this:
> 
>  pkg-config --exact-version 9.0 --variable=sdkdir libxul

like pkg-config --variable=sdkdir libxul = 9.0 ?
tough that would break with 9.0.1.

>  but... but... that doesn't work either, does it, because _if_
> xulrunner-dev is installed and it's xulrunner-10.0-dev, then we're
> f****d, because that file libxul.pc is exclusively-named.
> 
> 
> > The good news for you is that
> > xulrunner 10 will stay there for a while and /might/ be what is released
> > in wheezy.
> 
>  argh - actually that's _bad_ news, for exactly the reasons above.
> not only can it not be compiled (against xulrunner-9) but also it's
> xulrunner-10 which is severely borked.
> 
>  hmm... i wonder if xulrunner 11 is similarly borked?

pyxpcom doesn't build with xulrunner 11.

Mike