501300 - Allow to build the js shell against the libmozjs shared library

Status: RESOLVED DUPLICATE of bug 461996

(Core :: JavaScript Engine, defect)

Description

[Mike Hommey [:glandium]]

Attachment: patch

The only two hidden symbols that the js shell binary uses are js_IntervalNow and js_StrictlyEqual. How about making these two public ? It doesn't seem to me to be an exposure of strictly internal API, and would allow to build the js shell against the libmozjs shared library.

Comment 1

[Mike Hommey [:glandium]]

Attachment: patch

Better without Debian specific context lines.

Comment 2

[Jason Orendorff [:jorendorff]]

There's now a public JS_StrictlyEqual which the shell can use.  js_StrictlyEqual can remain hidden.

Comment 3

[Mike Hommey [:glandium]]

What about js_IntervalNow ?

Comment 4

[Mike Hommey [:glandium]]

Note, there is no JS_StrictlyEqual in 1.9.1.

Comment 5

[Jason Orendorff [:jorendorff]]

Ah, js_IntervalNow is already JS_FRIEND_API in tracemonkey tip.  Recent changes, I guess.

Comment 6

[Mike Hommey [:glandium]]

For the record, bugs 491617 and 491646 respectively make js_IntervalNow friendly API and create JS_StrictlyEqual.

Comment 7

[Mike Hommey [:glandium]]

Attachment: patch after patches from #491617 and #491646

This is what is left to do to make the js shell build against the js dynamic library after patches from bugs #491617 and #491646 are applied. I guess this applies fine on tracemonkey, though not tested. Only tested on 1.9.1 with the mentionned patches applied first.

Comment 8

[Mike Hommey [:glandium]]

Attachment: patch v2 after patches from #491617 and #491646

Even better when not relying on the lib being installed in dist/lib

Comment 9

[Jim Blandy :jimb]

BTW, Mike, if you just say "bug 491617" and "bug 491646" (no "#") then bugzilla will turn those into links.

Comment 10

[Jim Blandy :jimb]

Comment on attachment 386221 [details] [diff] [review]
patch v2 after patches from #491617 and #491646

This patch seems to be based on a pretty old tree.  The shell is in its own subdirectory now.  Could you adapt the patch to the current tm tree?

Comment 11

[Mike Hommey [:glandium]]

Attachment: patch for tracemonkey trunk

The previous patch was against 1.9.1. Against tracemonkey trunk, the approach needs to be slightly different. Note the use LD_LIBRARY_PATH in js/src/Makefile.in. The alternative to this is to have run-mozilla.sh shipped with spidermonkey, but that seemed bloat to me.
Also note JS_StrictlyEqual is already used on trunk.

Comment 12

[Jim Blandy :jimb]

Does the revised patch work on Windows?  We can't put Unix-specific stuff in js/src/Makefile.in rules that everyone uses.

Comment 13

[Mike Hommey [:glandium]]

I /guess/ it works. The reason I guess so is that in dist/bin, where the shell is run from, there is also the mozjs dll, and windows reads dlls from the binary directory by default. LD_LIBRARY_PATH won't have an effect on this. OTOH, it may not work on OSX. I think it needs a different variable.

Alternatively, you can copy build/unix/run-mozilla in js/src/build/unix, and skip the hunk adding LD_LIBRARY_PATH=$(DIST)/lib.

Comment 14

[Jim Blandy :jimb]

I'd rather not drag run-mozilla into it if we can avoid it.  Are you able to test this patch on Windows and Mac?

Comment 15

[Mike Hommey [:glandium]]

(In reply to comment #14)
> I'd rather not drag run-mozilla into it if we can avoid it.  Are you able to
> test this patch on Windows and Mac?

Unfortunately, no. Can't you use the try server for that?

Comment 16

[Jim Blandy :jimb]

Oh, yes, we can!  (They've added some more columns to the try server since I last worried about it.)  I'll give it a shot.

Comment 17

[Jim Blandy :jimb]

When I tried to build on Ubuntu 9.04 with this patch applied, the build died with the following error:

c++ -o js  -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Wno-long-long -pedantic -fno-strict-aliasing -fshort-wchar -pthread -pipe  -DDEBUG -D_DEBUG -DDEBUG_jimb -DTRACING -g3 -O0  js.o    -lpthread          -Wl,-rpath-link,/bin -Wl,-rpath-link,/lib -L../dist/bin -L../dist/lib  ../editline/libeditline.a -L/usr/local/lib -lmozjs -ldl -lm      
js.o: In function `SrcNotes':
/home/jimb/mc/tm/js/src/obj~/shell/../../shell/js.cpp:1595: undefined reference to `js_common_atom_count'
js.o: In function `ProcessArgs':
/home/jimb/mc/tm/js/src/obj~/shell/../../shell/js.cpp:696: undefined reference to `js_InitJITStatsClass(JSContext*, JSObject*)'
/home/jimb/mc/tm/js/src/obj~/shell/../../shell/js.cpp:698: undefined reference to `jitstats_class'
/usr/bin/ld: js: hidden symbol `js_InitJITStatsClass(JSContext*, JSObject*)' isn't defined
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
make[2]: *** [js] Error 1
make[2]: Leaving directory `/home/jimb/mc/tm/js/src/obj~/shell'
make[1]: *** [libs] Error 2
make[1]: Leaving directory `/home/jimb/mc/tm/js/src/obj~'
make: *** [default] Error 2

If you like, we can meet on IRC and hash it out.

Comment 18

[Jim Blandy :jimb]

The above failure is in a debug build; the below is a non-debug Windows build.

cl -Fojs.obj -c  -DEXPORT_JS_API -DOSTYPE=\"WINNT5.2\" -DOSARCH=WINNT -I/e/builds/sendchange-slave/sendchange-win32-hg/build/js/src -I.. -I/e/builds/sendchange-slave/sendchange-win32-hg/build/js/src/shell -I. -I../../../dist/include -I../../../dist/include/nsprpub  -Ie:/builds/sendchange-slave/sendchange-win32-hg/build/objdir/dist/include/nspr         -GR- -TP -nologo -Zc:wchar_t- -W3 -Gy -Fdgenerated.pdb  -DNDEBUG -DTRIMMED -Zi -UDEBUG -DNDEBUG -O1 -MD            -FI ../mozilla-config.h -DMOZILLA_CLIENT /e/builds/sendchange-slave/sendchange-win32-hg/build/js/src/shell/js.cpp
js.cpp
link -NOLOGO -OUT:js.exe -PDB:js.pdb  -NXCOMPAT -SAFESEH -DYNAMICBASE  -MANIFEST:NO -LIBPATH:"e:/builds/sendchange-slave/sendchange-win32-hg/build/objdir/memory/jemalloc/crtsrc/build/intel" -NODEFAULTLIB:msvcrt -NODEFAULTLIB:msvcrtd -DEFAULTLIB:mozcrt19 -DEBUG -OPT:REF -OPT:nowin98   js.obj  e:/builds/sendchange-slave/sendchange-win32-hg/build/objdir/dist/lib/nspr4.lib e:/builds/sendchange-slave/sendchange-win32-hg/build/objdir/dist/lib/plc4.lib e:/builds/sendchange-slave/sendchange-win32-hg/build/objdir/dist/lib/plds4.lib   e:/builds/sendchange-slave/sendchange-win32-hg/build/objdir/dist/lib/js3250.lib  kernel32.lib user32.lib gdi32.lib winmm.lib wsock32.lib advapi32.lib
js.obj : error LNK2001: unresolved external symbol _js_FunctionClass
js.obj : error LNK2001: unresolved external symbol _js_ObjectOps
js.obj : error LNK2001: unresolved external symbol _js_GeneratorClass
js.obj : error LNK2001: unresolved external symbol _js_ScriptClass
js.exe : fatal error LNK1120: 4 unresolved externals

Comment 20

[Mike Hommey [:glandium]]

For the record, the errors in comment 17 come from symbols that are only present on debug builds. There are two ways around this: make these symbols friend API, or link statically when doing debug builds.
The errors in comment 18 are weird, because these symbols are supposed to be exported (they are JS_FRIEND_DATA). Someone with access to a windows build box should check the resulting libraries to take a look at the generated symbols. (Could these be mangled like some others in bug 501434 ?)