net-libs/xulrunner-2.0 and www-client/firefox-4.0-r1 successfully build with "- disable-ipc". Thus the need to return "ipc" USE-flag, as in previous ebilds. Also need to remove the dependency of dev-lang/yasm for architecture ppc Reproducible: Always
I don't see a KEYWORDREQ bug report yet, so let's just use this one for all lost arches. Needs =net-libs/xulrunner-2.0 and consequently media-libs/libvpx or a package.use.mask entry in the arch profile on "net-libs/xulrunner webm" (especially when USE=vpx is already masked for you, perhaps through bug #323727).
media-libs/libvpx-0.9.5 successfully compiles and works on my ppc32. The current ebuild net-libs/xulrunner-2.0-r1 for successful build requires the addition of section "src_configure()" for NOT x86/amd64 arch: mozconfig_annotate''- disable-ipc IPC code written ugly x86-specific...
(In reply to comment #2) > media-libs/libvpx-0.9.5 successfully compiles and works on my ppc32. > The current ebuild net-libs/xulrunner-2.0-r1 for successful build requires the > addition of section "src_configure()" for NOT x86/amd64 arch: > > mozconfig_annotate''- disable-ipc > > IPC code written ugly x86-specific... IPC is being made mandatory, if we do not find someone to step up and write the ipc code for ppc and other archs they will be left with ff-3.x this was one of the main reasons all archs that could not be tested on where drop'd from keywords.
Adjusted summary as the old one was way too ambiguous to find this bug via search...
At first: mozilla-2.0/ipc/chromium/src/build/build_config.h -#elif defined(__ppc__) +#elif defined(__PPC__) I do not know why the __ppc___ is checked, not __PPC__ The second case is more complicated: mozilla-2.0/ipc/chromium/src/base/data_pack.cc A cursory study of the code has not yet allowed me to fix the working of the IPC. Build is successful, but the plug-ins (gnash, for example) do not work .. Somehow later I'll try to look code in detail. And while I have everything works well without IPC.
On behalf of the prefix team, leave the missing keywords dropped until someone has time/motivation to test it (if it isn't done and you want to remove old versions from the tree, please do so).
(In reply to comment #5) > At first: > mozilla-2.0/ipc/chromium/src/build/build_config.h > -#elif defined(__ppc__) > +#elif defined(__PPC__) > I do not know why the __ppc___ is checked, not __PPC__ Because on e.g. Darwin, __ppc__ and __ppc64__ are defined :) So check both, not just one.
Created attachment 272075 [details, diff] ppc support If someone from ppc herd could test and confirm working or not working would be appreciated.
(In reply to comment #8) > If someone from ppc herd could test and confirm working or not working would be > appreciated. Without data_pack.cc it will fail to link.
(In reply to comment #9) > (In reply to comment #8) > > If someone from ppc herd could test and confirm working or not working would be > > appreciated. > > Without data_pack.cc it will fail to link. Did you actually test the patch? It did not fail to link on any of my systems, just for the record data_pack.cc has not been used in many moons.
(In reply to comment #10) > Did you actually test the patch? It did not fail to link on any of my systems, > just for the record data_pack.cc has not been used in many moons. What are your USE? net-libs/xulrunner-2.0.1 "alsa (consolekit) dbus (ipc) (policykit) webm -crashreporter -custom-optimization -debug -gconf -libnotify -startup-notification -system-sqlite -wifi" ... ../../staticlib/components/libnecko.a(race.o): In function `race_decode_decompress': race.c:(.text+0x180): undefined reference to `_restgpr_30_x' ../../staticlib/components/libnecko.a(nameprep.o): In function `nameprep_map_id11': nameprep.c:(.text+0x70): undefined reference to `_restgpr_30_x' ../../staticlib/components/libnecko.a(nameprep.o): In function `nameprep_prohibited_id11': nameprep.c:(.text+0xe0): undefined reference to `_restgpr_30_x' ../../staticlib/components/libnecko.a(nameprep.o): In function `nameprep_unassigned_id11': nameprep.c:(.text+0x150): undefined reference to `_restgpr_30_x' ../../staticlib/components/libnecko.a(nameprep.o): In function `nameprep_biditype_id11': ...
(In reply to comment #11) > (In reply to comment #10) > > Did you actually test the patch? It did not fail to link on any of my systems, > > just for the record data_pack.cc has not been used in many moons. > > What are your USE? > > net-libs/xulrunner-2.0.1 "alsa (consolekit) dbus (ipc) (policykit) webm > -crashreporter -custom-optimization -debug -gconf -libnotify > -startup-notification -system-sqlite -wifi" > > ... > > ../../staticlib/components/libnecko.a(race.o): In function > `race_decode_decompress': > race.c:(.text+0x180): undefined reference to `_restgpr_30_x' > ../../staticlib/components/libnecko.a(nameprep.o): In function > `nameprep_map_id11': > nameprep.c:(.text+0x70): undefined reference to `_restgpr_30_x' > ../../staticlib/components/libnecko.a(nameprep.o): In function > `nameprep_prohibited_id11': > nameprep.c:(.text+0xe0): undefined reference to `_restgpr_30_x' > ../../staticlib/components/libnecko.a(nameprep.o): In function > `nameprep_unassigned_id11': > nameprep.c:(.text+0x150): undefined reference to `_restgpr_30_x' > ../../staticlib/components/libnecko.a(nameprep.o): In function > `nameprep_biditype_id11': > ... These are actually gcc undefines, please post your emerge --info
Created attachment 272251 [details, diff] ppc-atomic-ops-support.patch This should complete the support for ppc :)
(In reply to comment #13) > This should complete the support for ppc :) Confirm working.
*** Bug 365997 has been marked as a duplicate of this bug. ***
(In reply to comment #14) > (In reply to comment #13) > > This should complete the support for ppc :) > > Confirm working. PPC is now supported in main tree no need to continue to patch. Just need a ppc member to test and keyword. Thanks to those who helped testing.
Created attachment 273381 [details] build log (ppc64) PPC64 seems to be suffering from some derivative of https://bugzilla.mozilla.org/show_bug.cgi?id=618485
(In reply to comment #17) > Created attachment 273381 [details] > build log (ppc64) > > PPC64 seems to be suffering from some derivative of > https://bugzilla.mozilla.org/show_bug.cgi?id=618485 Wrong bug for ppc64... The proper one: https://bugzilla.mozilla.org/show_bug.cgi?id=627664 it haven't been touched since February so I would be grateful if you could apply patch provided there. On ppc is good to go, as soon as you sanitize: xulrunner-2.0.1-r1.ebuild: append-flags -mno-avx That flag is x86/amd64 specific.
Marked ~ppc/~ppc64. Thanks to all involved!
Segfaults on alpha/ia64, sigbuses on ia64... On arm bug 362237 needs to be fixed
(In reply to comment #20) > Segfaults on alpha/ia64, sigbuses on ia64... I obviously meant sigbuses on sparc...
+ 25 Aug 2011; Markus Meier <maekke@gentoo.org> firefox-6.0.ebuild: + add ~arm, bug #360427 + xulrunner-2* isn't building yet.
(In reply to comment #22) > + 25 Aug 2011; Markus Meier <maekke@gentoo.org> firefox-6.0.ebuild: > + add ~arm, bug #360427 > + > > xulrunner-2* isn't building yet. the patch will not be backported for xulrunner-2.0, everything is going into getting fx-6 to stable which will allow us to kill xulrunner-2.0 all together.
Removing xulrunner from the summary since its going to get removed
No more 4...
ALL arch's should be fine to add keywords to fx-7.0.1-r1, if your arch can not add its keywords please drop your keywords from Mozilla ebuilds. Thunderbird will get a bump that will also allow you to re-keyword, this should be available later tonight.
(In reply to comment #26) > ALL arch's should be fine to add keywords to fx-7.0.1-r1, if your arch can not > add its keywords please drop your keywords from Mozilla ebuilds. Thunderbird > will get a bump that will also allow you to re-keyword, this should be > available later tonight. You mean that any arch that can't keyword fx-7* due to it failing to work, must drop keywords from all firefox versions?!
(In reply to comment #27) > (In reply to comment #26) > > ALL arch's should be fine to add keywords to fx-7.0.1-r1, if your arch can not > > add its keywords please drop your keywords from Mozilla ebuilds. Thunderbird > > will get a bump that will also allow you to re-keyword, this should be > > available later tonight. > > You mean that any arch that can't keyword fx-7* due to it failing to work, must > drop keywords from all firefox versions?! Exactly. We do not have the time with the new release schedule to support multiple versions of mozilla products for a few archs.
(In reply to comment #28) > Exactly. We do not have the time with the new release schedule to support > multiple versions of mozilla products for a few archs. How about we do something like grub-2 does, and say in metadata.xml that the mozilla team only supports >=firefox-${XXX} <herd restrict=">=www-client/firefox-${XXX}">mozilla</herd> That would let architectures that the mozilla herd doesn't have time to support manage these packages as they have time, without slowing the mozilla team down.
I'm happy to give firefox-7 another try on HPPA. If it fails and is too difficult to fix, then I'll gladly drop the remaining HPPA keywording too. It's not like web browsing on decade old systems without proper X11 support is a pleasure to do, let alone a requirement (it started out more as a proof of concept).
HPPA keywording dropped.
~arm keywords restored for firefox-7/8.
~alpha/~ia64 done its unlikely its going to work on sparc, but i'll have a look...
Let's give this another go.
Marked ~hppa: =www-client/firefox-10.0.1-r1 This will require sys-devel/binutils-2.22-r1 : PATCHVER="1.2" when going stable, if ever it does.
FYI sigbuses on sparc... Jory, you were taking care of this if you remember :D
If you feel I have closed your bug and it is still a current issue, please reopen and update it completely. We will not work bugs that have no ebuild in tree any longer or can not be reproduced with a current system. Thank You for your support and understanding The Mozilla Team
