Official firefox-pgo thread

Ranguvar · 2009-11-26 23:46:33

blasse, do you mind also testing with the latest patch from this bug?

blasse · 2009-11-27 13:03:02

I could try. This patch is already commited to HG and probably will be backported to 3.6 tree with rc version.

Mogger · 2009-12-02 23:57:49

Ranguvar wrote:

You shouldn't need to disable the jemalloc PGO patch to enable the potential PGO fix patch anymore.

Sorry for the late reply; I did try that at first, but then I got the same error as I posted earlier. For now I've disabled PGO, hope it'll work with future releases.

KushedVapors · 2009-12-08 13:57:12

so i finished installing firefox-pgo through yaourt. Do i need to have xulrunner installed because i didnt whenit was compiling. Each time i try to launch firefox i get "Firefox is already running, but is not responding. To open a new window, you must first close the existing Firefox process, or restart your system."

Ranguvar · 2009-12-08 15:24:21

firefox-pgo* is independent of XULRunner.

That error has always been common with Firefox.
Do what the prompt suggests -- try a `killall firefox` and/or `killall firefox-bin` before starting.

toxygen · 2009-12-12 02:49:20

blasse - i hope you dont mind me asking questions about Ranguvar's pgo-minefiled package here, I much prefer to ask here than the aur page.

Ranguvar- I successfully build your pgo-minefield package, but I keep getting segmentation faults when running the sunspider tests (fails at random points). I tried commenting out the pgo-fix, the jemalloc patch, and eventually all the patches, and though it builds pgo successfully, i keep getting the segmentation faults. also tried commenting out the line so i could build the latest trunk (and used my own separate PKGBUILD which keeps nearly all your additions, except it does load the latest trunk automatically) with similar results. I have not tried building a non-pgo build, but I'll try that next.

I'm not sure what the issue could be, though I did get a 'compiler error' during one of the builds (with your original PKGBUILD). it's sad, the last 3.7a1 release i could build with no errors (and no problems during usage) was 091115, nearly a month ago. any ideas?

also, regarding the trunk builds, I've wondered why on most builds using hg, i see some status updates as the process starts (downloading, updating, refreshing) but on yours i see nothing, so i dont know if it fails to download (as some packages report - "transaction aborted, rolling back"). is that something i can add to the PKGBUILD?

Last edited by toxygen (2009-12-12 02:53:56)

Ranguvar · 2009-12-12 04:44:15

Whereas most PKGBUILDs use Pacman's built-in support for VCSs, in order to auto-fetch the latest code, mine does not, because I like manually updating the version fetched when a revision passes the Firefox build bot tests.

I suspect that's the reason, but I'm not sure
Perhaps I should add some manual messages, yes.

As for the problems in the browser itself, I haven't *used* firefox-pgo-minefield in a bit, I must admit.
It seems the error, though, is with upstream... if you could do a non-PGO build (just comment out the make profiledbuild line, it already does a normal build first), that would be very helpful
Actually, you may need to disable PGO in the mozconfig file too. I'm not 100% positive what takes priority.

If you find a new rev to be working well, just let me know, and I'll update to that rev

Last edited by Ranguvar (2009-12-12 04:44:47)

KushedVapors · 2009-12-14 08:24:14

sorry for not replyin quick enough but the problem was a firefox profile. I started up the profile manager and chose the default profile and everything worked but it was still the same as regular firefox. Not that much of a big performance boost. Swiftfox worked the best for me in crunchbang which but i dont like how that guy chooses to be closed source(very suspicious).

harryNID · 2009-12-24 22:28:59

WOO HOO!!!

I finally got a stable build. After building this about 20-30 times, Yay!

Here is what I did for people with similar issues.

I narrowed it down to two things it's either "export CFLAGS" and "export CXXFLAGS" or "libgnomeui" or both.

I changed my CFLAGS and CXXFLAGS to this:

export CFLAGS="-march=i686 -mtune=pentium4 -O2 -pipe -fomit-frame-pointer"
export CXXFLAGS="-march=i686 -mtune=pentium4 -O2 -pipe -fomit-frame-pointer"

and deleted "libgnomeui" from the makedepends.

I don't know which it could be but I'm thinking it's mainly a CFLAGS issue not picking up "march=native" correctly on my machine (and as stated in other posts).

Also, as I said I deleted "libgnomeui". Here's my logic behind that. First, I never had a segfault issue until I started using the new PKGBUILD using "libgnomeui" as a makedepend. Since I am running a light Fluxbox setup I have no need for "libgnomeui" permanently so after the build I would delete it. Do you think by not having that installed all the time I was causing the segfaults myself? As I said "libgnomeui" could or could not be an issue. What do you guys think? I never thought about leaving it installed long enough after the build to test my theory so it will remain that, just a hypothesis. Irregardless, by leaving it out of the makedepends I still managed to get a good build.

Just thought I would share my finding so other might ponder solutions to theirs.

bobdob · 2009-12-24 23:08:33

I have no problem with firefox segfaulting, but if I leave libgnomeui install I get lots of error messages in stderr. They disappear though if I remove it, so maybe there is some problems related to libgnomeui.

toxygen · 2009-12-24 23:09:03

yes, if you had it installed and then removed it after the build, it would cause problems, as firefox build will check for gnome ui libraries (during the configure process). if you remove it after you build it, then whatever parts of firefox that depend on gnomeui (which was detected at build) will cause problems. I was building with the dependency on gnomeui deleted as well until 3.6b5 and ranguvar's minefield packages, which is when i started getting segfaults until i *enabled* libgnomeui.
but i think i have a good stable build now and will try disabling it as well again, since i dont like to have extra packages i dont use either.

i also disable :
#ac_add_options --disable-gnomeui --disable-gnomevfs
in mozconfig to make sure no gnome dependcies are added, but this might be overkill, and i havent tested it to see if it'll cause problems. trying to rebuild now though.

Last edited by toxygen (2009-12-24 23:11:06)

jugs · 2010-01-10 13:06:01

Tried building the new firefox-pgo-beta (3.6 RC1), and I just got the:

/usr/lib/firefox-3.6/run-mozilla.sh: Line 131: 4630 Segmentation fault "$prog" ${1+"$@"}

.. immediately upon launch!

Has anyone found a solution?

Pank · 2010-01-10 16:38:53

I get the same error. I though it had been fixed. The last time it turned up it was a bug related to compilation for core2 processors. You will find it if you go few pages back.

harryNID · 2010-01-10 20:32:53

That is what I've been getting with all the betas until recently. I just compiled the new version here no problem having followed the steps again I posted in #459. I'm running a P4 and and for some reason this package doesn't like: (on my machine)

export CFLAGS="-march=native -O2 -pipe"
export CXXFLAGS="-march=native -O2 -pipe"

I also have been taking out the 'libgnomeui>=2.24.1' option in the makedepends. If you want to leave it in then I suggest that you don't uninstall after building (haven't tried that though). As stated previously, I run a light WM so I don't want the bloat. I think (IMO) that this causes a lot of issues especially for those that choose to uninstall it after building the package.

As "toxygen" stated:

yes, if you had it installed and then removed it after the build, it would cause problems, as firefox build will check for gnome ui libraries (during the configure process). if you remove it after you build it, then whatever parts of firefox that depend on gnomeui (which was detected at build) will cause problems.

Try this and see if it builds. Replace in PKGBUILD:

export CFLAGS="-march=*1 -mtune=*2 -O2 -pipe -fomit-frame-pointer"
export CXXFLAGS="-march=*1 -mtune=*2 -O2 -pipe -fomit-frame-pointer"

*1 i686 or x86_64 (I'm running 32-bit so I'm guessing on the 64-bit option)
*2 cpu-type

Note: cpu-type can be referenced here:
http://gcc.gnu.org/onlinedocs/gcc/i386- … 64-Options

Also I would recommend trying to build a version with and without 'libgnomeui>=2.24.1' with the above flags to see if it really makes a difference or not. Mine builds fine without it but you can go with whatever it takes to work for you.

The above works for me so you could try it and if it works then post your results.

toxygen · 2010-01-19 19:10:28

just finished building 3.6rc2, and after commenting out some of the patches (which gave errors at the beginning of the build) it works well. for once the jscript test for sunspider didnt crash! i also have the lowest results since 11/19 pgo-trunk build last year.
now if only we can get the patches from the firefox-kde-opensuse packages applied to pgo-minefield or pgo-beta

harryNID wrote:

I also have been taking out the 'libgnomeui>=2.24.1' option in the makedepends. If you want to leave it in then I suggest that you don't uninstall after building (haven't tried that though). As stated previously, I run a light WM so I don't want the bloat. I think (IMO) that this causes a lot of issues especially for those that choose to uninstall it after building the package.

i was able to remove the dependency on gnomeui, but had problems building. the solution that worked for me was to have gconf installed but not libgnomeui (or any of the other deps of libgnomeui). after building, removing gconf gives some warning but firefox itself doesnt seem to crash. i guess it's only required as a makedepend

Berseker · 2010-01-23 09:12:47

no one is trying to update this PKGBUILD for the new release 3.6? I know that there are several issues with new libpng, libjpeg in [testing] repo, but maybe someone has created a prototype PKGBUILD?

bobdob · 2010-01-23 14:05:16

Berseker wrote:

no one is trying to update this PKGBUILD for the new release 3.6? I know that there are several issues with new libpng, libjpeg in [testing] repo, but maybe someone has created a prototype PKGBUILD?

You just need to bump the pkgver and it compiles fine, if you don't have testing enabled.

pyther · 2010-01-23 14:09:42

Or just grab the libpng patch from svn for the xulrunner. Apply it and you should be good to go.

May I ask what everyone is having problems with? I just applied the png patch from svn and firefox works just fine for me. Am I a lucky one?

bobdob · 2010-01-23 14:24:18

They might not know about the patch, since no one has posted it on the aur comments or here.

pyther · 2010-01-23 14:26:49

I made mention about it in the firefox-pgo-beta comments, but anyways here is also a thread about firefox 3.6 and libpng http://bbs.archlinux.org/viewtopic.php?id=89242

dalingrin · 2010-01-23 21:20:56

I am trying to build firefox-pgo under a 32bit chroot but it is exiting with:

 /usr/include/bits/local_lim.h:39:26: error: linux/limits.h: No such file or directory
In file included from /usr/include/errno.h:36,
                 from /home/erik/build/firefox-pgo/src/mozilla-1.9.1/config/pathsub.c:45:
/usr/include/bits/errno.h:25:26: error: linux/errno.h: No such file or directory

Any idea what dependency I am missing? I have both base and base-devel groups installed.

pyther · 2010-01-24 15:57:55

pyther@tux: pacman -Qo  /usr/include/linux/limits.h                           ~
/usr/include/linux/limits.h is owned by linux-api-headers 2.6.32.5-1

And as I am using testing:

Allan McRae @ arch-dev-public ML wrote:

linux-api-headers-2.6.32.5-1
- rename kernel-headers - too similar to kernel26-headers (FS#17655)

Find it odd though firefox needs kernel headers to build :-/

Last edited by pyther (2010-01-24 16:10:21)

toxygen · 2010-01-24 16:37:49

pyther wrote:

Find it odd though firefox needs kernel headers to build :-/

I believe all kernel modules need files from kernel headers to build
[edit] was just reading an nvidia thread, my brain is not full awake. nevermind the above

Last edited by toxygen (2010-01-24 16:38:30)

jugs · 2010-01-24 17:45:15

So what's going on with firefox-pgo now? I don't understand why a [testing] package would delay the update. I would like to get 3.6 going already..

pyther · 2010-01-24 17:51:33

@jugs just use the firefox-pgo-beta pkgbuild and change the pkgver from 3.6rc2 to 3.6. It should compile just fine if you are not using testing. If you are using testing just apply the libpng patch that can be found in the svn (arch) for xulrunner.

Arch Linux

#451 2009-11-26 23:46:33

Re: Official firefox-pgo thread

#452 2009-11-27 13:03:02

Re: Official firefox-pgo thread

#453 2009-12-02 23:57:49

Re: Official firefox-pgo thread

#454 2009-12-08 13:57:12

Re: Official firefox-pgo thread

#455 2009-12-08 15:24:21

Re: Official firefox-pgo thread

#456 2009-12-12 02:49:20

Re: Official firefox-pgo thread

#457 2009-12-12 04:44:15

Re: Official firefox-pgo thread

#458 2009-12-14 08:24:14

Re: Official firefox-pgo thread

#459 2009-12-24 22:28:59

Re: Official firefox-pgo thread

#460 2009-12-24 23:08:33

Re: Official firefox-pgo thread

#461 2009-12-24 23:09:03

Re: Official firefox-pgo thread

#462 2010-01-10 13:06:01

Re: Official firefox-pgo thread

#463 2010-01-10 16:38:53

Re: Official firefox-pgo thread

#464 2010-01-10 20:32:53

Re: Official firefox-pgo thread

#465 2010-01-19 19:10:28

Re: Official firefox-pgo thread

#466 2010-01-23 09:12:47

Re: Official firefox-pgo thread

#467 2010-01-23 14:05:16

Re: Official firefox-pgo thread

#468 2010-01-23 14:09:42

Re: Official firefox-pgo thread

#469 2010-01-23 14:24:18

Re: Official firefox-pgo thread

#470 2010-01-23 14:26:49

Re: Official firefox-pgo thread

#471 2010-01-23 21:20:56

Re: Official firefox-pgo thread

#472 2010-01-24 15:57:55

Re: Official firefox-pgo thread

#473 2010-01-24 16:37:49

Re: Official firefox-pgo thread

#474 2010-01-24 17:45:15

Re: Official firefox-pgo thread

#475 2010-01-24 17:51:33

Re: Official firefox-pgo thread

Board footer