"JS_DefineFunctions" only defines the first function under Debian Lenny
Edward L. Fox
I faced a strange problem when I'm using SpiderMonkey under Debian.
"JS_DefineFunctions" only defines the first function in my
JSFunctionSpec, but leaves the remaining functions undefined.
Part of my code:
-------------------- 8< --------------------
...
static JSFunctionSpec global_functions[] = {
{ "print", Print, 0 },
{ "quit", Quit, 0 },
{ "gc", GC, 0 },
{ 0 }
};
...
if (!JS_DefineFunctions(cx, global, global_functions))
return QUIT_ERROR;
...
-------------------- 8< --------------------
Then run this program:
-------------------- 8< --------------------
js> print
function print() {
[native code]
}
js>
js> quit
(stdin):2: ReferenceError: quit is not defined
js> gc
(stdin):3: ReferenceError: gc is not defined
-------------------- 8< --------------------
If I move "quit" to the first line of "global_functions", then "quit"
will be defined properly and leave "print" undefined instead. That is
to say, only the first function in JSFunctionSpec will be defined in
JavaScript context.
This snippet of code will export all functions to JavaScript context
as I desired:
-------------------- 8< --------------------
if (!JS_DefineFunctions(cx, global, &global_functions[0]))
return QUIT_ERROR;
if (!JS_DefineFunctions(cx, global, &global_functions[1]))
return QUIT_ERROR;
if (!JS_DefineFunctions(cx, global, &global_functions[2]))
return QUIT_ERROR;
-------------------- 8< --------------------
I tested the code both under Debian Lenny and Ubuntu 6.04, only Debian
faces this problem. Ubuntu 6.04 exports all the functions properly as
I want.
The malfunctional version under Debian Lenny:
-------------------- 8< --------------------
$ dpkg -s libmozjs-dev
Package: libmozjs-dev
Status: install ok installed
Priority: optional
Section: libdevel
Installed-Size: 836
Maintainer: Mike Hommey <glan...@debian.org>
Architecture: all
Source: xulrunner
Version: 1.8.1.4-2
Depends: libmozjs0d (>= 1.8.1.4), libmozjs0d (<< 1.8.1.4-2.1~), libnspr4-dev
Conflicts: mozilla-browser (<< 2:1.8)
Description: Development files for the Mozilla SpiderMonkey JavaScript library
This library provides the embeddable JavaScript/ECMAScript engine from
the Mozilla project (used among others by the Mozilla, Epiphany, Firefox
browsers as well as by the iPlanet WebServer).
.
Install this package if you wish to develop your own programs using the
Mozilla SpiderMonkey JavaScript library.
.
Homepage: http://www.mozilla.org/js/
-------------------- 8< --------------------
The properly working version under Ubuntu:
-------------------- 8< --------------------
$ dpkg -s libsmjs-dev
Package: libsmjs-dev
Status: install ok installed
Priority: optional
Section: libdevel
Installed-Size: 1104
Maintainer: Marek Habersack <gre...@debian.org>
Architecture: i386
Source: spidermonkey
Version: 1.5rc6a-2
Replaces: spidermonkey-dev (<= 1.5rc5a-1)
Depends: libsmjs1 (= 1.5rc6a-2), libnspr-dev
Conflicts: spidermonkey-dev (<= 1.5rc5a-1)
Description: Development files for the SpiderMonkey JS library
This package contains the development files (includes and
static libraries) you will need if you want to embed the
SpiderMonkey JavaScript engine in your application.
-------------------- 8< --------------------
Regards,
Edward L. Fox
franky...@gmail.com
> Hi SpiderMonkey users under Debian,
>
> I faced a strange problem when I'm using SpiderMonkey under Debian.
> "JS_DefineFunctions" only defines the first function in my
> JSFunctionSpec, but leaves the remaining functions undefined.
>
> Part of my code:
>
> -------------------- 8< --------------------
> ...
> static JSFunctionSpec global_functions[] = {
> { "print", Print, 0 },
> { "quit", Quit, 0 },
> { "gc", GC, 0 },
> { 0 }
>
> };
>
Try to initialize all the variables of the structure and see if the
problem is solved:
{ "print", Print, 0, 0, 0 },
{ "quit", Quit, 0, 0, 0 },
{ "gc", GC, 0, 0, 0 },
{ 0, 0, 0, 0, 0 }
Franky.
Edward L. Fox
On 9/4/07, franky...@gmail.com <franky...@gmail.com> wrote:
> [...]
>
> Try to initialize all the variables of the structure and see if the
> problem is solved:
>
> { "print", Print, 0, 0, 0 },
> { "quit", Quit, 0, 0, 0 },
> { "gc", GC, 0, 0, 0 },
> { 0, 0, 0, 0, 0 }
Thanks for your help. But in fact it's not because of that. After
carefully read the source code and checked some archives of Mozilla, I
found this message:
In the following change:
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/js/src&command=DIFF_FRAMESET&file=jsapi.h&rev2=3.121&rev1=3.120
types of fields of JSFunctionDesc are changed.
Related information:
3.121 <bre...@mozilla.org> 2006-04-27 10:58
Awesome patch from Andreas <mqm...@web.de> to avoid creating
unnecessary objects for primitives being operated on via methods
(334261, r=me).
The bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=334261.
So this problem happens because the Debian's package developer(s)
defined "-DMOZILLA_1_8_BRANCH" macro when he/they compiled the
package. If I didn't define this when compiling my program, my program
would fail to run.
OK, I can work around this problem by simply adding this macro to my
project. But here comes another problem: how can I know whether I need
to define that macro? pkg-config doesn't report that. Further more, if
my program is compiled under a platform which doesn't define that
macro and my program defines that, it will break, too. Is there any
way to determine whether my program needs that macro during
"./configure" time? Or should I always ship a copy of spidermonkey's
source code so that I can build it up myself on any platforms and
never trust its built-in library?
>
> Franky.
>
> _______________________________________________
> dev-tech-js-engine mailing list
> dev-tech-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>
Regards,
Edward L. Fox
Igor Bukanov
As a workaround you can check for MOZILLA_1_8_BRANCH macro and use
different initializers when it is set. But SpiderMonkey should
provider simpler way to get backward-compatibility. Please file a bug
at https://bugzilla.mozilla.org/enter_bug.cgi?product=Core against
JavaScript about that.
Regards, Igor
On 04/09/07, Edward L. Fox <edy...@gmail.com> wrote:
> Hi Franky,
>
> On 9/4/07, franky...@gmail.com <franky...@gmail.com> wrote:
> > [...]
> >
> > Try to initialize all the variables of the structure and see if the
> > problem is solved:
> >
> > { "print", Print, 0, 0, 0 },
> > { "quit", Quit, 0, 0, 0 },
> > { "gc", GC, 0, 0, 0 },
> > { 0, 0, 0, 0, 0 }
>
Edward L. Fox
On 9/4/07, Igor Bukanov <ig...@mir2.org> wrote:
> Hi Edward,
>
> As a workaround you can check for MOZILLA_1_8_BRANCH macro and use
> different initializers when it is set. But SpiderMonkey should
> provider simpler way to get backward-compatibility. Please file a bug
> at https://bugzilla.mozilla.org/enter_bug.cgi?product=Core against
> JavaScript about that.
Thanks for you advice!
But my problem is not about that. My problem came out because of
these:
1. The pre-built package of SpiderMonkey is provided by the Debian
developers. They defined that macro during their compilation.
2. There is no document to tell me that I should define the macro too
in my own code. And pkg-config doesn't provide that macro definition,
either. So I missed the macro.
3. So my program is incompatible with the pre-built SpiderMonkey. But
unfortunately it compiled well. So I can't notify that until I run my
problem and the unit tests fail. And it's very difficult to figure out
why it broke.
4. Although I found out the problem, I still can't determine whether I
should define that macro in my code during configure time. So I can't
ensure my code could still work in the others system.
So, checking the macro in my code does no help at all. In fact my code
doesn't care whether or not that macro is defined - the only thing I
should do is to ensure the macro definition is precisely the same with
the pre-built package.
>
> Regards, Igor
>
> [...]
Regards,
Edward L. Fox
Igor Bukanov
> So, checking the macro in my code does no help at all. In fact my code
> doesn't care whether or not that macro is defined - the only thing I
> should do is to ensure the macro definition is precisely the same with
> the pre-built package.
Right, what you need is to set the macro at the compile time if and
only if SM is compiled with it. Then you you still need to use ifdefs
in your code to use one or another form of JSFunctionSpec.
I guess it is possible to detect the macro value using configure
hacks, but I agree that this is a mess. So please file a bug about it.
Regards, Igor