There is a noteworthy conflict on Karmic if you try to install libmozjs-dev because it conflicts with anything based on xulrunner 1.9. I can’t begin to explain why the Mozilla developers hold Spidermonkey to 1.8, but because of how the upstream Debian crew package it, this breaks things.
We all know I am hardly smart enough to have my hands on a keyboard in the first place, but I think the underlying issue is Debian folks insist on building all the xulrunner libraries with the name “libmozjs” instead of simply “libjs” — the latter is the default from source.
I really wanted Elinks with JScript, and I didn’t care about all the other crap Debian developers build into. What in blue blazes do I know about Lua scripting? So I typically build Elinks from the latest source (0.12pre5 at this moment). After downloading the source for Spidermonkey, I poked around at various ways to make it work without breaking the way Ubuntu runs Firefox.
Lacking the experience and understanding for tweaking the build configurations, I simply ran the basic build without installing. Then I examined where the Elinks build script looks for Spidermonkey, hoping to find a place in the file system Ubuntu didn’t use normally. One of the choices was the /opt/spidermonkey directory and I used that. But I didn’t know how to put that in the installer instructions, and my searching for simple instructions turned up nothing I could identify. So I examined the package contents and structure for the way Ubuntu builds libmozjs and echoed that under /opt/spidermonkey with an include and lib folder, and simply moved the files from the build manually. I had to poke around in the build directories of Spidermonkey, and found all but one file which appears on the Ubuntu package file list — jsosdep.h. I have no idea what difference that makes. But it seems the primary difference is the name of the actual runtime file — libjs versus libmozjs.
Once I had them in place, the Elinks configure script found it all and gave me a Spidermonkey build. Then I had to make sure Ubuntu knew to include this in the ld.conf. In /etc/ld.so.conf.d directory I created a libjs.conf file with this one line:
/opt/spidermonkey/lib/
and ran sudo ldconfig, hoping there would be no runtime conflicts. For now, I can run Firefox on JScript heavy sites without trouble, so I guess it’s working as I hoped. I’m sure there are plenty of folks who know more about this than I do, so feel free to comment.
Pingback: Spidermonkey on Ubuntu Karmic « Do What's Right
Pingback: Spidermonkey on Ubuntu Karmic | Ubuntu-News - Your one stop for news about Ubuntu
Thanks for posting! I’m investigating the same issue on Fedora. The only apparent difference is that — while my system has a the /etc/ld.so.conf.d directories with files having contents consistent with what’s given here — the ldconfig manpage doesn’t mention that it processes the /etc/ld.so.conf.d directory, only the /etc/ld.so.conf directory (and /usr/lib & /lib).
I’ll try it anyway and see what happens.
My
/etc/ld.so.confhas this line:include /etc/ld.so.conf.d/*.conf.Thanks, Ed; I subsequently found that line in mine, too.
This is probably the wrong place for this, but it’s the only thread I’ve found that discusses use of elinks 0.12pre5 with SpiderMonkey 1.8.
Basically, I did the above, but am not getting results.
Running “elinks –version” indicates “ECMAScript (SpiderMonkey)” and “Scripting (Spidermonkey ECMAScript);” however, running “elinks -config-dump” produces the following:
set ecmascript.enable = 0
This happens even when I create a a ~/.elinks/elinks.conf file with a line to explicitly set this flag.
The only way I can get “elinks -config-dump” to indicate ecmascript is enabled is to include the command line switch “-eval ‘set ecmascript.enable = 1′”
Further, in *all* cases on a trial web page, I get a message suggesting I enable JavaScript in my browser in order to see content.
I find no configuration settings/indications for ECMAScript in any elinks run-time menu commands.
Finally, just for completeness, the option ecmascript.error_reporting also displays as 0 unless I explicitly set it in the elinks command line. Even when this guy is set, though, I get no errors.
Does anyone have knowledge/experience about the subtleties of configuring elinks?
Otherwise, it would appear my only option is to modify source code and rebuild the app.
You are on-topic, as far as I am concerned.
I have such experience, but I must warn you the answer is not going to bless you. The developers will confess Elinks has implemented only a precious few portions of ECMAScript functions. They want to do a lot more (think BLinux), but find it hard going without the GUI. I suppose to get a much better discussion of it from them, you would probably have to join their mailing list, linked on their website. I have found them quite willing to answer my questions, if sometimes a little on the slow side.
Their source package includes a large number of experimental patches not normally enabled in one of the subdirectories, so check there before you dig too deeply into the source. I am incompetent on such matters, so I can’t help you.
Thanks for the advice, Ed!
(BTW, I rebuilt with ecmascript.enable = 1 as the default value, and the darn app still perceived JavaScript as being disabled!)
actually, I have a question about java scripting in elinks with spider
monkey support.
clearly it is there, I just ignore those sites who claim it needs to be
enabled. still is there any firm information in either documentation that
states that the combination of elinks with spider monkey yields a java
script friendly browser? Say if I wanted to site the info for an article.
thanks much,
Karen
All I know is what I have experienced. In times past, I have seen Elinks open new windows on JScript commands embedded in webpages. That was some time ago. As noted in previous comments you’ll see we have been unable to get much from it on Ubuntu. I suspect the Elinks developers are still struggling with implementation. I have also tested SEE as their new favorite for JScript support, and SEE crashes miserably, making a mess of the display, and making it very hard to recover control of the Xterm window. Apparently the Elinks developers are not using Debian nor Debian derivatives for their work. You can read their documents, but I’m not sure what it will tell you. Most of it is frankly over my head.