User-Agent: Midori/0.3 (X11; OpenBSD; U; fr-fr) WebKit/531.2+ Build Identifier: As of now, js fails to build on OpenBSD because either pthread_attr_get_np() or pthread_getattr_np() don't exist. pthread_attr_init() + pthread_attr_getstack() won't work on OpenBSD, so we have to use pthread_stackseg_np() instead. Reproducible: Always
Created attachment 512815 [details] [diff] [review] use pthread_stackseg_np() on OpenBSD First proposition for a patch, minimizing the diff. Ideally, the codepath for OpenBSD wouldn't need pthread_attr_t/pthread_attr_init/pthread_attr_destroy, so maybe it should be inside its own #ifdef block like macos code. We might still need the last part of the function changing what's returned depending on JS_STACK_GROWTH_DIRECTION (though we don't build mozilla on hppa yet)
Comment on attachment 512815 [details] [diff] [review] use pthread_stackseg_np() on OpenBSD Stealing. NPOTB, so no risk but even than approval might not come until after FF4 branched.
What's the procedure to get that commited now that there's r+ and a2.0+ ? Should i do another patch putting the OpenBSD code inside its own #ifdef block for the sake of readability ?
Just land it on the TM tree if you have commit access, or find someone who has.
Comment on attachment 512815 [details] [diff] [review] use pthread_stackseg_np() on OpenBSD Sorry, too late for 2.0.
Created attachment 527210 [details] [diff] [review] Include pthread_np.h on OpenBSD too for pthread_stackseg_np() Duh!. pthread_np.h also needs to be included on OpenBSD for pthread_stackseg_np() to be defined... sorry i missed that one.
Pushed to cedar.
Pushed: http://hg.mozilla.org/mozilla-central/rev/6588e8a0c8c5 (oups, I didn't meant to mark the bug as fixed before...)