On Mon, Mar 22, 2010 at 11:09:24AM +0100, Mike Hommey wrote: > On Mon, Mar 22, 2010 at 09:49:13AM +0100, Mike Hommey wrote: > > On Sun, Mar 21, 2010 at 02:59:06PM +0000, Darren Salt wrote: > > > Package: libmozjs2d > > > Version: 1.9.1.8-5 > > > Severity: important > > > > > > I tried building gxine against libmozjs-dev 1.9.2-0preview1. It FTBFS at > > > link > > > time, as follows: > > > > > > script_engine.o: In function `JS_ISSPACE': > > > /usr/include/mozjs/jsstr.h:741: undefined reference to `js_X' > > > /usr/include/mozjs/jsstr.h:741: undefined reference to `js_Y' > > > /usr/include/mozjs/jsstr.h:741: undefined reference to `js_A' > > > > > > Building against 1.9.1.8-5 works fine (which is why this bug is not of an > > > RC > > > severity). > > > > > > However, use of JS_CCODE, JS_ISSPACE and a few other macros will trigger > > > this > > > failure in both versions since js_A, js_X and js_Y are declared as extern > > > in > > > <mozjs/jsstr.h> but are not exported by the library. > > > > Just for the record, the main problem with spidermonkey headers is that > > there is near to no distinction between public API and private API. I > > think JS_CCODE and JS_ISSPACE are the typical example of stuff that is > > in a header only to be shared accross the library itself, but not > > necessarily meant to be exported. > > > > Though, arguably, JS_* symbols are usually for FRIEND_API (i.e. > > semi-private), and js_* symbols are usually PUBLIC_API. > > That's the contrary. > > Another example of things that are probably not meant to be exported: > js_AnyName_str and other constants from jsxml.h.
So, according to upstream, JS_ISSPACE and friends from jsstr.h are not supposed to be public API at all, and should not have been used by gine in the first place. Would you prefer that I reassign this bug to gxine or that I leave it wontfix ? Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org