331776 - Allow to build a standalone js (spidermonkey) binary

Status: RESOLVED DUPLICATE of bug 433083

(Core :: JavaScript Engine, enhancement)

Description

[Mike Hommey [:glandium]]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.8.0.1) Gecko/20060313 Debian/1.5.dfsg+1.5.0.1-4 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.8.0.1) Gecko/20060313 Debian/1.5.dfsg+1.5.0.1-4 Firefox/1.5.0.1

Please allow to build a standalone js (spidermonkey) binary while building, for example, firefox.
Patch coming.

Reproducible: Always

Comment 1

[Mike Hommey [:glandium]]

Attachment: Patch

(note this patch is against xulrunner 1.8.0.1 ; should apply correctly on trunk)

Comment 2

[Benjamin Smedberg]

You mean jsshell? What do we need to build that for? I'm not absolutely opposed, but I'd like to understand.

Comment 3

[Mike Hommey [:glandium]]

We have a jsshell in debian that used to be built using the spidermonkey tarball, which was not updated often, and is now aging in your ftp archive.
We now provide this shell from the xulrunner source code.

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 216329 [details] [diff] [review]
Patch

ohh yes this would be nice.

why not build this always, instead of making it conditional on a configure switch? I think we have too many of those already.

Comment 5

[Mike Hommey [:glandium]]

Well, tell me what you all agree to have and I'll adapt the patch (binary name, option name or no option at all, whatever...)

Comment 6

[Blake Kaplan (:mrbkap) (inactive)]

Can the xpcshell (in js/src/xpconnect/shell) get in on the libreadline configure goodness?

Comment 7

[Brendan Eich [:brendan]]

See also bug 97954 and bug 62307.  It would be *great* to have a unified build system for standalone SpiderMonkey and built-into-Mozilla-apps libmozjs.

There will be a SpiderMonkey JS1.6 rc1 tarball soon, btw.

/be

Comment 8

[Brian Crowder]

Could we reasonably call this a dupe of bug 97954?  Mike:  I would be happy to work with you on this, if you're still interested in it.  Ideally, js/ should have its own configure script compatible with the main tree build but capable of being run on its own.

Comment 9

[Brian Crowder]

Taking ownership of this until it is marked as a dupe (if ever)

Comment 10

[Mike Hommey [:glandium]]

I'm not sure I like the idea for a small part of the tree to use automake and libtool where all the rest only use autoconf... I'd be much more in favor of something like what is currently done with nsprpub

Comment 11

[Benjamin Smedberg]

I agree, we want to use an autoconf + rules.mk solution similar to NSPR, not jump into automake.

Comment 12

[Brian Crowder]

Okay, I will model my work on the NSPR stuff then.  Can we close the other bug, perhaps?  WONTFIX?

Comment 13

[Brian Crowder]

Attachment: naive, broken first stab

There is a lot wrong with this patch.  I have (I think incorrectly) changed the DEPTH= setting in Makefile.in, and stolen configure.in and some files from config/ from the nsprpub/ build.  Where obvious, I have changed the names of nspr things to be "js" things or removed things that didn't make sense.  I also used autoscan to update configure.in automagically.  I've probably missed parts, and broken things.

Applying this patch will probably require you to manually create a config/ directory under js/

Comment 14

[Brian Crowder]

I need to add a sane "all" target (or something) to Makefile.in to convince it the generated makefile that there is still some work to do.  Also, it would be nice to have a toplevel Makefile that calls the Makefile in js/src (even if that's all it does).

Comment 15

[Mikhail T.]

Instead of producing browser-specific jsshel (or js) executables, IMO, spidermonkey should be decoupled from the browsers (like NSS and NSPR are), and made available separately.

Currently, the most recently released is js-1.5.tar.gz, which is over a year old. Comparing its contents with mozilla/js subdirectory of Firefox-2.0 reveals numerous changes.

Configuring firefox ``--with-system-js'' should be THE PREFERRED way. Following it, the various Mozilla software packages will be able to share one more component (in addition to NSS and NSPR) -- instead of each package building their own. And that would be a good thing...

Comment 16

[Brian Crowder]

Mikhail:  That's the plan (though it might be easier to do the autoconf thing in the context of Moz2).  Also, there should be a js-1.6 either currently staged, or coming soon.

Comment 17

[Mike Hommey [:glandium]]

Attachment: Patch for xpcshell

As suggested in comment #6

Comment 18

[Martynas Venckus]

(In reply to comment #15)
> Instead of producing browser-specific jsshel (or js) executables, IMO,
> spidermonkey should be decoupled from the browsers (like NSS and NSPR are), and
> made available separately.
> 
> Currently, the most recently released is js-1.5.tar.gz, which is over a year
> old. Comparing its contents with mozilla/js subdirectory of Firefox-2.0 reveals
> numerous changes.
> 
> Configuring firefox ``--with-system-js'' should be THE PREFERRED way. Following
> it, the various Mozilla software packages will be able to share one more
> component (in addition to NSS and NSPR) -- instead of each package building
> their own. And that would be a good thing...

I'm in favor of this change.

Comment 19

[Mike Hommey [:glandium]]

Attachment: Additional patch

This additional patch is necessary to correctly build with gcc 4.2 using system wrappers instead of -fvisibility=hidden.

Without this
patch, the build fails with the following error:
js/src/js.c:149: undefined reference to `readline'
js/src/js.c:153: undefined reference to `add_history'
/usr/bin/ld: js: hidden symbol `readline' isn't defined
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status

And a similar error with xpcshell.cpp.

Comment 20

[Reed Loden [:reed]]

What's the status of this bug? Is this something that is wanted for 1.9?

Comment 21

[Benjamin Smedberg]

No, I've been sitting on it because we need to do something very different and moz2 changes the linkage problem anyway.

Comment 22

[Benjamin Smedberg]

Comment on attachment 216329 [details] [diff] [review]
Patch

We're not going to do this, in preference for the solution in bug 97954

Comment 23

[Mikhail T.]

(In reply to comment #22)
> (From update of attachment 216329 [details] [diff] [review])
> We're not going to do this, in preference for the solution in bug 97954

What's meant by "this"? The solution to bug 97954 still calls for a standalone SpiderMonkey tarball, and that's all I was asking for -- two years ago...

Comment 24

[Brian Crowder]

jimb might be a better owner.  Or should we WONTFIX this?