[Desktop-packages] [Bug 908508]
(In reply to Landry Breuil from comment #103) (In reply to David Mandelin from comment #102) This is getting really confusing--I feel like I need to back up a few steps. Yes, i'm also confused. 1. First off, do you still need to leave out the executableAllocators in jscntxt.h? If you have the JITs now, then it seems like you don't even need to patch jscntxt.h. I'm going to assume you do, and continue, but if we don't need to do anything, that would be great. There are platforms where there's no JIT (and hence no ExecutableAllocator), for example sparc64 macppc/sysv abi. So we have to #ifdef ENABLE_ASSEMBLER out the execAlloc uses. OK. Good to know. 2. Second, if possible, it'd be nice to do something small and simple that just fixes the immediate problem. The immediate problem, IIUC, is that you can't have the executableAllocators in JSContext, and #ifdef ENABLE_ASSEMBLER in jscntxt.h doesn't work. So, what about just providing a dummy class for ExecutableAllocator on SPARC? Would that work? You could put it in a .cpp file guarded by !ENABLE_ASSEMBLER. To me, the immediate problem is that i've a diff that works, but it breaks some tests in subtle ways just because ENABLE_ASSEMBLER=1 is not propagated anymore under shell/ with my diff. Sure, but if we try to get ENABLE_ASSEMBLER=1 propagated, it seems like it's going to involve either a gross hack, or a lot of work to redo the options everywhere. So I was looking for an easier way first. ExecutableAllocator.h has the arch-dependant machinery, and it #errors out on the archs we care about in this bug report.. because (at least!) there's no implementation for 'cacheFlush', which seems to require writing some low-level asm, and i have no idea if it can be made a nop. Which archs do have a problem? It looks like there is an implementation for SPARC. We're still missing PPC, I guess. x86/x86_64 provides an empty implementation, but iirc i tried adding ppc to also use that empty implem and it failed to build. I think an empty implementation should build on PPC. Whether it's correct, I don't know, but it only matters if using the JITs. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to thunderbird in Ubuntu. https://bugs.launchpad.net/bugs/908508 Title: Firefox/Thunderbird 10 FTBFS on powerpc in js/src/yarr/pcre Status in The Mozilla Firefox Browser: In Progress Status in “firefox” package in Ubuntu: Fix Released Status in “thunderbird” package in Ubuntu: Fix Released Bug description: Debian has the fix, so I'll add it to the branch and it should work with the next upload. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/908508/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 908508]
This is getting really confusing--I feel like I need to back up a few steps. 1. First off, do you still need to leave out the executableAllocators in jscntxt.h? If you have the JITs now, then it seems like you don't even need to patch jscntxt.h. I'm going to assume you do, and continue, but if we don't need to do anything, that would be great. 2. Second, if possible, it'd be nice to do something small and simple that just fixes the immediate problem. The immediate problem, IIUC, is that you can't have the executableAllocators in JSContext, and #ifdef ENABLE_ASSEMBLER in jscntxt.h doesn't work. So, what about just providing a dummy class for ExecutableAllocator on SPARC? Would that work? You could put it in a .cpp file guarded by !ENABLE_ASSEMBLER. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to thunderbird in Ubuntu. https://bugs.launchpad.net/bugs/908508 Title: Firefox/Thunderbird 10 FTBFS on powerpc in js/src/yarr/pcre Status in The Mozilla Firefox Browser: In Progress Status in “firefox” package in Ubuntu: Fix Released Status in “thunderbird” package in Ubuntu: Fix Released Bug description: Debian has the fix, so I'll add it to the branch and it should work with the next upload. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/908508/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 908508]
I would suggest making the minimal change that actually works and doesn't make things more confusing. Exactly what that would be, I don't know without trying things out. My *guess* would be that adding JS_ENABLE_JIT to Makefile.in and using it only in the places you need here would be it. I'm not sure exactly what blocks you are talking about in comment 98, but it sounds like a good idea. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to thunderbird in Ubuntu. https://bugs.launchpad.net/bugs/908508 Title: Firefox/Thunderbird 10 FTBFS on powerpc in js/src/yarr/pcre Status in The Mozilla Firefox Browser: In Progress Status in “firefox” package in Ubuntu: Fix Released Status in “thunderbird” package in Ubuntu: Fix Released Bug description: Debian has the fix, so I'll add it to the branch and it should work with the next upload. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/908508/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 908508]
(In reply to Landry Breuil from comment #89) I've looked at try logs, and yes ENABLE_ASSEMBLER=1 is not set on the commandline when building under shell/ with the patch. Ah, OK. I looked at it in my Linux VM, and I really thought I saw ENABLE_ASSEMBLER in the command line for js.o, but given that that makes no sense, it makes sense that you found it's the opposite. :-) (In reply to Mike Hommey [:glandium] from comment #90) Yes. That these things are in Makefile.in is a mistake anyways. JSC sets those flags in what we imported as assembler/wtf/Platform.h, which seems reasonable. In fact, I see they set ENABLE_ASSEMBLER in there depending on various conditions, which is maybe why the patch works on most platforms already. js-config.h also seems like a reasonable place, although since there is already ENABLE_ASSEMBLER and ENABLE_JIT stuff in Platform.h, maybe it will be easier to keep consistent if we do it there. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to thunderbird in Ubuntu. https://bugs.launchpad.net/bugs/908508 Title: Firefox/Thunderbird 10 FTBFS on powerpc in js/src/yarr/pcre Status in The Mozilla Firefox Browser: In Progress Status in “firefox” package in Ubuntu: Fix Released Status in “thunderbird” package in Ubuntu: Fix Released Bug description: Debian has the fix, so I'll add it to the branch and it should work with the next upload. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/908508/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 908508]
Mike, what exactly do you mean by Platform.h being or not being a public header? Do you mean being installed to an include/ dir, or do you mean getting included into jsapi.h? AFAICT it is neither at the moment, just trying to see what you're getting at. Landry, it's definitely a maze. Sorting it out proper would be a lot of work so I definitely don't expect you to fix everything as part of this patch. It seems important to make sure ENABLE_ASSEMBLER is consistent, though, so combined with Mike's point about Platform.h not being public, it seems that we shouldn't try to set ENABLE_ASSEMBLER, ENABLE_YARR_JIT or ENABLE_JIT in the Makefile, and we shouldn't use them in public header files. One idea is to create a new thing that is set on the same conditions when ENABLE_ASSEMBLER is set and put that in js-config.h. Then you could use that in jscntxt.h without causing any problems. Then we could use macros to check that the two are consistent on one of the other files, like YarrJIT.cpp. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to thunderbird in Ubuntu. https://bugs.launchpad.net/bugs/908508 Title: Firefox/Thunderbird 10 FTBFS on powerpc in js/src/yarr/pcre Status in The Mozilla Firefox Browser: In Progress Status in “firefox” package in Ubuntu: Fix Released Status in “thunderbird” package in Ubuntu: Fix Released Bug description: Debian has the fix, so I'll add it to the branch and it should work with the next upload. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/908508/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 908508]
Landry, following up on a hint from billm, I got your patch to work on Linux with this addition: diff -r e7bbcbb6c24a js/src/jscntxt.h --- a/js/src/jscntxt.h Tue Mar 13 17:42:33 2012 -0700 +++ b/js/src/jscntxt.h Tue Mar 13 18:32:46 2012 -0700 @@ -64,6 +64,7 @@ #include js/HashTable.h #include js/Vector.h #include vm/Stack.h +#include assembler/jit/ExecutableAllocator.h #ifdef _MSC_VER #pragma warning(push) I'm not quite sure what's going on, but it kind of seems like ENABLE_ASSEMBLER=1 is not being set for all the files in the build, and so different object files get different definitions of JSRuntime, which causes the trc field to get overwritten with junk, and then you crash. Your patch does modify how ENABLE_ASSEMBLER is set, so it seems vaguely plausible that could be the problem. The strange thing is that it seems like js.cpp is the file that doesn't get ENABLE_ASSEMBLER=1, but I do see it being set on the command line to build js.o. And it also doesn't make much sense that the patch above would solve the problem. Bug 731110 might just make things easy: if you don't have to make execAlloc_ conditional on ENABLE_ASSEMBLER (because you'll have the assembler), then you won't have to modify jscntxt.h and the Makefile.in, and it should just work. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to thunderbird in Ubuntu. https://bugs.launchpad.net/bugs/908508 Title: Firefox/Thunderbird 10 FTBFS on powerpc in js/src/yarr/pcre Status in The Mozilla Firefox Browser: In Progress Status in “firefox” package in Ubuntu: Fix Released Status in “thunderbird” package in Ubuntu: Fix Released Bug description: Debian has the fix, so I'll add it to the branch and it should work with the next upload. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/908508/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 908508]
Comment on attachment 600506 Use YARR interpreter instead of PCRE on platforms where YARR JIT is not supported (m-c patch) Review of attachment 600506: - Stealing the review because Chris doesn't have time. Looks fine--just one little note about this and bug 731110 but you probably already know anyway. ::: js/src/Makefile.in @@ +351,5 @@ +OSAllocatorWin.cpp \ +PageBlock.cpp \ +YarrInterpreter.cpp \ +YarrPattern.cpp \ +YarrSyntaxChecker.cpp \ This probably conflicts with patch 3 in bug 731110. Not sure exactly how you guys want to deal with that, just pointing it out. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to thunderbird in Ubuntu. https://bugs.launchpad.net/bugs/908508 Title: Firefox/Thunderbird 10 FTBFS on powerpc in js/src/yarr/pcre Status in The Mozilla Firefox Browser: In Progress Status in “firefox” package in Ubuntu: Fix Released Status in “thunderbird” package in Ubuntu: Fix Released Bug description: Debian has the fix, so I'll add it to the branch and it should work with the next upload. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/908508/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 908508]
(In reply to Landry Breuil from comment #70) So, what's needed to fix this ? Sorry, i have no idea why it changes behaviour for linux debug builds, since it's only shuffling ifdefs around... and the testsuite log isnt really verbose, besides saying there's a failure. You could try running one of the failing tests, say bug706316.js, with the -so option in the harness, which will show the command line and output. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to thunderbird in Ubuntu. https://bugs.launchpad.net/bugs/908508 Title: Firefox/Thunderbird 10 FTBFS on powerpc in js/src/yarr/pcre Status in The Mozilla Firefox Browser: In Progress Status in “firefox” package in Ubuntu: Fix Released Status in “thunderbird” package in Ubuntu: Fix Released Bug description: Debian has the fix, so I'll add it to the branch and it should work with the next upload. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/908508/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 740815]
(In reply to Randall Leeds from comment #49) Sorry to revive an old thread, but I wanted to voice my thoughts for posterity. Thanks for the input. I don't think we're planning changing much right now, but at some point I think we'll want to do a new source release and it will be good to keep this in mind. I think the point about version numbering going with ABI rather than language features makes sense. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-python-extras in Ubuntu. https://bugs.launchpad.net/bugs/740815 Title: [FFe] Updates to enable us to drop xulrunner from main Status in The Mozilla Firefox Browser: Fix Released Status in “couchdb” package in Ubuntu: Fix Released Status in “gluezilla” package in Ubuntu: Fix Released Status in “gnome-python-extras” package in Ubuntu: Fix Released Status in “gtk-vnc” package in Ubuntu: Fix Released Status in “gwt” package in Ubuntu: Fix Released Status in “icedtea-web” package in Ubuntu: Fix Released Status in “libreoffice” package in Ubuntu: Fix Released Status in “libreoffice-l10n” package in Ubuntu: Fix Released Status in “mono” package in Ubuntu: Fix Released Status in “mozvoikko” package in Ubuntu: Fix Released Status in “packagekit” package in Ubuntu: Fix Released Status in “swt-gtk” package in Ubuntu: Fix Released Status in “xulrunner-1.9.2” package in Ubuntu: Fix Released Status in “xulrunner-2.0” package in Ubuntu: Fix Released Bug description: Binary package hint: xulrunner-2.0 Based on the new Firefox release schedule (http://people.mozilla.com/~sayrer/2011/temp/process.html), we need to drop xulrunner from main as unsupportable, else I'm going to risk spending nearly 100% of my time continually providing support for this across up to 5 stable releases, when most applications using it are in universe and probably aren't interesting to much more than 1% of our users. This is a catch-all-bug driving that work. The plan of action is: couchdb - We will introduce a libmozjs source package for main, totally decoupled from the Firefox release process. This will be used by couchdb (and possibly other spidermonkey embedders in univese in the future) icedtea-web - Firefox already provides an SDK now. We will build icedtea-web against Firefox rather than xulrunner. It seems that icedtea-web only really needs Firefox or xulrunner to do a version check in order to decide whether to turn on some XPCOM bits (which are turned off when built against newer Firefox builds). We should consider making this a pure NPAPI plugin and drop the mozilla dependency entirely (but perhaps not Natty timeframe) swt-gtk - We will update swt-gtk to the stable 3.6 2 release, turning on webkit support and turning off mozilla support. This requires some updates to applications in universe which hardcode SWT.MOZILLA. libreoffice-l10n/libreoffice - declares a build-depend on xulrunner- dev, so we need to investigate why and see if we can remove that. gtk-vnc - has a xulrunner-dev build-depend purely for the NPAPI headers. We can build this against firefox-dev, but it really should just ship its own headers (NPAPI is cross-browser anyway) gnome-python-extras - this is a tricky one. The only thing I can think of now is to turn of python-gtkmozembed and drop everything which uses it (not sure how popular that would make me) mozvoikko - this is a firefox extension with binary components anyway, so must be built against firefox (xulrunner and firefox versions won't be kept in sync in the future anyway) packagekit - has a build-depend for the NPAPI browser plugin. Same as above really - either ship its own headers or build against firefox- dev. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/740815/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
