Currently www-client/elinks requires dev-lang/spidermonkey (0) slot zero or spidermonkey-1.8.5-r4 to build & run against. However, I was getting elinks crashing while encountering webpages using javascript. For example: /usr/lib64/libmozjs185.so.1.0(JS_EvaluateUCScriptForPrincipals+0xc1)[0x32ad44fa31] /usr/lib64/libmozjs185.so.1.0(JS_EvaluateScriptForPrincipals+0x72)[0x32ad44fb42] /usr/lib64/libmozjs185.so.1.0(JS_EvaluateScript+0x22)[0x32ad44fbe2] So went configured the elinks.ebuild to require slot 17 (ie. spidermonkey-17.0.0-r3 slot 17), and ELinks seem to build and run just fine. Whether it avoids the previously mentioned coredump, I'm not sure yet. But the same web pages do now render and scroll properly. Reproducible: Always
I have not recently read into any of ELinks source code or build documentation, or queried any of the developers on their current build recommendations. This I'll likely do, if this bug stalls along. ;-) (ELinks is pretty much my go to browser, instead of Links, whenever X/Xorg fails; or I'm working on slow Pentium3 boxes and prefer working via the command line or virtual consoles.)
I recall attempting to make elinks build and run properly against spidermonkey:17 , however I wasn't successful when I did this. I believe the naive attempt simply makes elinks not respond to javascript at all (ie, you cannot even force on javascript support at runtime, it just doesn't work); and attempts I made at rectifying this caused elinks to segfault all the time. However, if you have had better luck and have evidence that javascript still works in elinks after building against spidermonkey-17, please post your patch(es)!
Do you have a particularly good example of a simple website that will crash elinks with spidermonkey-1.8.5 ? I tried a few and it works fine for me..
FYI, once the ebuild has been massaged appropriately so that it will actually start building against spidermonkey:17, you will begin to see errors like this at compile time: [MAKE all] src/ecmascript make[3]: Entering directory `/var/tmp/portage/www-client/elinks-0.12_pre6-r1/work/elinks-0.12pre6/src/ecmascript' [CC] src/ecmascript/ecmascript.o [CC] src/ecmascript/location-goto.o [CC] src/ecmascript/spidermonkey-shared.o In file included from spidermonkey-shared.c:10:0: ../.././src/ecmascript/spidermonkey-shared.h:37:2: error: unknown type name ‘uint8’ ../.././src/ecmascript/spidermonkey-shared.h:45:28: error: unknown type name ‘uintN’ spidermonkey-shared.c:113:32: error: unknown type name ‘uintN’ make[3]: *** [spidermonkey-shared.o] Error 1 Otherwise, either the ./configure script is disabling ECMAscript support by not finding the correct library, or it's still actually building against spidermonkey-1.8.5
Shortly after filing this bug, either elinks or spidermonkey was updated and has been work OK from what I see since. I did not verify the elinks configure script was finding and using spidermonkey-17.0.0. I also did not verify javascript websites were being properly rendered by elinks. I assumed since elinks built fine with the javascript USE flag alongside spidermonkey-17.0.0, that elinks did find and use spidermonkey or javascript! Sounds like you have more experience with elinks & javascript, so I'd be alright as marking this as won't fix.
