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. Mike -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
