You can use the source for firefox for your spidermonkey builds, this will put your current. I will attach in just a minute an updated ebuild fully working, threading support is needed no matter what as configure will fail if not avaliale.
Created attachment 256504 [details, diff] Use current firefox releases for spidermonkey release media/changes This is fully tested and working hope this will get you all back on track.
Alexis: I talked about this with Jory on IRC. I think it would be nice if we had a newer version since it doesn't look like Mozilla will release newer stand-alone JS tarballs anytime soon. If you're not interested anymore, I'd be happy to take over (or co-maintain).
(In reply to comment #2) > Alexis: I talked about this with Jory on IRC. I think it would be nice if we > had a newer version since it doesn't look like Mozilla will release newer > stand-alone JS tarballs anytime soon. If you're not interested anymore, I'd be > happy to take over (or co-maintain). > There will be no more standalone tarballs, all distros have been moved to using the firefox release media and compiling it just as I have done in the ebuild.
(In reply to comment #0) > You can use the source for firefox for your spidermonkey builds, this will put > your current. I will attach in just a minute an updated ebuild fully working, > threading support is needed no matter what as configure will fail if not > avaliale. > The comment about threading being required is invalid, this has been worked around in the attached patch.
(In reply to comment #2) > Alexis: I talked about this with Jory on IRC. I think it would be nice if we > had a newer version since it doesn't look like Mozilla will release newer > stand-alone JS tarballs anytime soon. If you're not interested anymore, I'd be > happy to take over (or co-maintain). > Please do so, I'm not using it anymore, and, to be honest, I'm a bit ashamed since I've not been maintaining it for ages. At a time nobody seemed interested in adopting it so I kept myself as official maintainer, I'd be very glad if you could pick it up and remove me from maintainers.
Good then, this will work out great for all of us. Jory, want to co-maintain?
Hmm, the new ebuild doesn't seem to compile for me. I get a bunch of errors about undefined references to PR_Lock, PR_Unlock, and a number of other PR_* functions. I thought those should be part of NSPR, but I have that installed (4.8.6).
(In reply to comment #7) > Hmm, the new ebuild doesn't seem to compile for me. I get a bunch of errors > about undefined references to PR_Lock, PR_Unlock, and a number of other PR_* > functions. I thought those should be part of NSPR, but I have that installed > (4.8.6). > interesting compiles fine here, as co-matinainer no, please place mozilla as herd tho we will assist when needed.
Created attachment 256874 [details, diff] Proposed patch to allow compilation with USE=threadsafe Doesn't seem to want to compile with USE=threadsafe here either, fails when linking jsapi-tests. The problematic part looks like this in the build log: x86_64-pc-linux-gnu-g++ -o jsapi-tests -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 -march=amdfam10 -O2 -pipe -fno-strict-aliasing -pthread -pipe -DNDEBUG -DTRIMMED -Os -freorder-blocks -fno-reorder-functions tests.o selfTest.o testPropCache.o testXDR.o testIntString.o testIsAboutToBeFinalized.o testSameValue.o testDebugger.o testDefineGetterSetterNonEnumerable.o testExtendedEq.o -lpthread -Wl,-O1 -Wl,--as-needed -Wl,-rpath-link,/bin -Wl,-rpath-link,/lib -L../dist/bin -L../dist/lib -Wl,-R/usr/lib64 -L/usr/lib64 -lplds4 -lplc4 -lnspr4 -lpthread -ldl ../libjs_static.a -ldl -lm ../libjs_static.a(jsapi.o): In function `JS_Finish': jsapi.cpp:(.text+0xedb): undefined reference to `PR_DestroyLock' jsapi.cpp:(.text+0xeec): undefined reference to `PR_DestroyCondVar' jsapi.cpp:(.text+0xefd): undefined reference to `PR_DestroyCondVar' jsapi.cpp:(.text+0xf0e): undefined reference to `PR_DestroyLock' jsapi.cpp:(.text+0xf1f): undefined reference to `PR_DestroyCondVar' jsapi.cpp:(.text+0xf30): undefined reference to `PR_DestroyCondVar' jsapi.cpp:(.text+0xf41): undefined reference to `PR_DestroyLock' ../libjs_static.a(jsapi.o): In function `JS_Init': jsapi.cpp:(.text+0x104d): undefined reference to `PR_NewLock' jsapi.cpp:(.text+0x1065): undefined reference to `PR_NewCondVar' jsapi.cpp:(.text+0x1081): undefined reference to `PR_NewCondVar' jsapi.cpp:(.text+0x10ad): undefined reference to `PR_NewLock' ...etc.. so the nspr libraries containing the PR_* symbols are there like they should be, but the libjs_static.a wanting to use the symbols is too late in the command line. I'm not that familiar with the mozilla sources, but changing the library order in js/src/jsapi-tests/Makefile.in is enough to allow the compilation to finish at least here.
(In reply to comment #9) > Created an attachment (id=256874) [details] > Proposed patch to allow compilation with USE=threadsafe > > Doesn't seem to want to compile with USE=threadsafe here either, fails when > linking jsapi-tests. > > The problematic part looks like this in the build log: > > x86_64-pc-linux-gnu-g++ -o jsapi-tests -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 -march=amdfam10 -O2 -pipe -fno-strict-aliasing > -pthread -pipe -DNDEBUG -DTRIMMED -Os -freorder-blocks -fno-reorder-functions > tests.o selfTest.o testPropCache.o testXDR.o testIntString.o > testIsAboutToBeFinalized.o testSameValue.o testDebugger.o > testDefineGetterSetterNonEnumerable.o testExtendedEq.o -lpthread -Wl,-O1 > -Wl,--as-needed -Wl,-rpath-link,/bin -Wl,-rpath-link,/lib -L../dist/bin > -L../dist/lib -Wl,-R/usr/lib64 -L/usr/lib64 -lplds4 -lplc4 -lnspr4 -lpthread > -ldl ../libjs_static.a -ldl -lm > ../libjs_static.a(jsapi.o): In function `JS_Finish': > jsapi.cpp:(.text+0xedb): undefined reference to `PR_DestroyLock' > jsapi.cpp:(.text+0xeec): undefined reference to `PR_DestroyCondVar' > jsapi.cpp:(.text+0xefd): undefined reference to `PR_DestroyCondVar' > jsapi.cpp:(.text+0xf0e): undefined reference to `PR_DestroyLock' > jsapi.cpp:(.text+0xf1f): undefined reference to `PR_DestroyCondVar' > jsapi.cpp:(.text+0xf30): undefined reference to `PR_DestroyCondVar' > jsapi.cpp:(.text+0xf41): undefined reference to `PR_DestroyLock' > ../libjs_static.a(jsapi.o): In function `JS_Init': > jsapi.cpp:(.text+0x104d): undefined reference to `PR_NewLock' > jsapi.cpp:(.text+0x1065): undefined reference to `PR_NewCondVar' > jsapi.cpp:(.text+0x1081): undefined reference to `PR_NewCondVar' > jsapi.cpp:(.text+0x10ad): undefined reference to `PR_NewLock' > ...etc.. > > so the nspr libraries containing the PR_* symbols are there like they should > be, but the libjs_static.a wanting to use the symbols is too late in the > command line. > > I'm not that familiar with the mozilla sources, but changing the library order > in js/src/jsapi-tests/Makefile.in is enough to allow the compilation to finish > at least here. > Include your emerge --info if you want to get this resolved.
Created attachment 256875 [details] build.log of threadsafe compile on amd64 Proposed patch is incorrect, I need the emerge --info if I am to fix the issue.
I should have made a note ... http://git.overlays.gentoo.org/gitweb/?p=proj/mozilla.git;a=commit;h=27c29e08bef9e19ad3695a1bc290ca50ec5e0566 track it via mozilla overlay. Dirkjan I will co-maintain if you still would like.
Created attachment 257014 [details] emerge --info
Created attachment 257016 [details] build.log for failing threadsafe compile on amd64 renamed to dev-lang/spidermonkey-1.9.2.13 in local overlay
I'm seeing the issue as well where I'm unable to compile dev-lang/spidermonkey-1.9.2.13.
(In reply to comment #14) > Created an attachment (id=257016) [details] > build.log for failing threadsafe compile on amd64 > > renamed to dev-lang/spidermonkey-1.9.2.13 in local overlay > (In reply to comment #15) > I'm seeing the issue as well where I'm unable to compile > dev-lang/spidermonkey-1.9.2.13. > What version of nspr do you all have installed?
Created attachment 258207 [details, diff] spidermonkey-1.9.2-nspr-includes.patch If anyone would test and report would speed things along, I do not see why it should change anything but who knows.
(In reply to comment #15) > I'm seeing the issue as well where I'm unable to compile > dev-lang/spidermonkey-1.9.2.13. > (In reply to comment #7) > Hmm, the new ebuild doesn't seem to compile for me. I get a bunch of errors > about undefined references to PR_Lock, PR_Unlock, and a number of other PR_* > functions. I thought those should be part of NSPR, but I have that installed > (4.8.6). > Okay finally I know what the problem is and I am addressing it, it is nothing more then as-needed causing the breakage.
Overlay is fixed, soon as I get a confirmation I will move it to the tree. Thanks for all the reports so far.
Seems to work for me! Can we add a src_test() to run some of the tests?
BTW, there is this QA notice, not sure if you see it too? * QA Notice: Package has poor programming practices which may compile * fine but exhibit random runtime failures. * jsvector.h:148: warning: dereferencing pointer 'dst' does break strict-aliasing rules Maybe we can send up a patch for that.
(In reply to comment #20) > Seems to work for me! Can we add a src_test() to run some of the tests? > Of course you can. (In reply to comment #21) > BTW, there is this QA notice, not sure if you see it too? > > * QA Notice: Package has poor programming practices which may compile > * fine but exhibit random runtime failures. > * jsvector.h:148: warning: dereferencing pointer 'dst' does break > strict-aliasing rules > > Maybe we can send up a patch for that. > I am sure I can push something up for it, soon as we get this in tree tho I will work on spidermonkey-2.0 which might have addressed it already.
*** Bug 266225 has been marked as a duplicate of this bug. ***
We now have 1.9.2.13 in the tree.
