[gentoo-user] Firefox-10.0.1 fails to compile on x86

[gentoo-user] Firefox-10.0.1 fails to compile on x86

[Mick]

Hi All,

The latest stable x86 firefox fails to compile:
====================================
/mnt/video/tmp_portage/portage/www-client/firefox-10.0.1/work/mozilla-release/obj-i686-pc-linux-gnu/config/nsinstall
-D ../../dist/sdk/lib
rm -f libxul.so
/usr/bin/python2.7
/mnt/video/tmp_portage/portage/www-client/firefox-10.0.1/work/mozilla-release/config/pythonpath.py
-I../../config /mnt/video/tmp_portage/portage/www-client/firefox-10.0.1/work/mozilla-release/config/expandlibs_exec.py
--uselist --  i686-pc-linux-gnu-g++  -fno-rtti -Wall -Wpointer-arith
-Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy
-Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof
-Wno-variadic-macros -Werror=return-type -march=pentium3 -pipe
-mno-avx -fno-exceptions -fno-strict-aliasing -std=gnu++0x
-fno-tree-vrp -pthread -ffunction-sections -fdata-sections -pipe
-DNDEBUG -DTRIMMED -g -O2 -fomit-frame-pointer -fPIC -shared
-Wl,-z,defs -Wl,--gc-sections -Wl,-h,libxul.so -o libxul.so
nsStaticXULComponents.o nsUnicharUtils.o nsBidiUtils.o nsRDFResource.o
   -lpthread -Wl,-O1 -Wl,--as-needed
-Wl,-rpath-link,/mnt/video/tmp_portage/portage/www-client/firefox-10.0.1/work/mozilla-release/obj-i686-pc-linux-gnu/dist/bin
-Wl,-rpath-link,/usr/lib    ../../toolkit/xre/libxulapp_s.a
../../staticlib/components/libnecko.a
../../staticlib/components/libuconv.a
../../staticlib/components/libi18n.a
../../staticlib/components/libchardet.a
../../staticlib/components/libjar50.a
../../staticlib/components/libstartupcache.a
../../staticlib/components/libpref.a
../../staticlib/components/libhtmlpars.a
../../staticlib/components/libimglib2.a
../../staticlib/components/libgkgfx.a
../../staticlib/components/libgklayout.a
../../staticlib/components/libdocshell.a
../../staticlib/components/libembedcomponents.a
../../staticlib/components/libwebbrwsr.a
../../staticlib/components/libnsappshell.a
../../staticlib/components/libtxmgr.a
../../staticlib/components/libcommandlines.a
../../staticlib/components/libtoolkitcomps.a
../../staticlib/components/libpipboot.a
../../staticlib/components/libpipnss.a
../../staticlib/components/libappcomps.a
../../staticlib/components/libjsreflect.a
../../staticlib/components/libcomposer.a
../../staticlib/components/libjetpack_s.a
../../staticlib/components/libtelemetry.a
../../staticlib/components/libjsdebugger.a
../../staticlib/components/libstoragecomps.a
../../staticlib/components/librdf.a
../../staticlib/components/libwindowds.a
../../staticlib/components/libjsctypes.a
../../staticlib/components/libjsperf.a
../../staticlib/components/libgkplugin.a
../../staticlib/components/libunixproxy.a
../../staticlib/components/libjsd.a
../../staticlib/components/libautoconfig.a
../../staticlib/components/libauth.a
../../staticlib/components/libcookie.a
../../staticlib/components/libpermissions.a
../../staticlib/components/libuniversalchardet.a
../../staticlib/components/libfileview.a
../../staticlib/components/libplaces.a
../../staticlib/components/libtkautocomplete.a
../../staticlib/components/libsatchel.a
../../staticlib/components/libpippki.a
../../staticlib/components/libwidget_gtk2.a
../../staticlib/components/libsystem-pref.a
../../staticlib/components/libimgicon.a
../../staticlib/components/libaccessibility.a
../../staticlib/components/libremoteservice.a
../../staticlib/components/libspellchecker.a
../../staticlib/components/libzipwriter.a
../../staticlib/components/libservices-crypto.a
../../staticlib/libjsipc_s.a ../../staticlib/libdomipc_s.a
../../staticlib/libdomplugins_s.a ../../staticlib/libmozipc_s.a
../../staticlib/libmozipdlgen_s.a ../../staticlib/libipcshell_s.a
../../staticlib/libgfx2d.a ../../staticlib/libgfxipc_s.a
../../staticlib/libhal_s.a ../../staticlib/libxpcom_core.a
../../staticlib/libucvutil_s.a ../../staticlib/libchromium_s.a
../../staticlib/libmozreg_s.a ../../staticlib/libgtkxtbin.a
../../staticlib/libthebes.a ../../staticlib/libycbcr.a
../../staticlib/libangle.a  -L../../dist/bin -L../../dist/lib -ljpeg
-lpng  ../../gfx/qcms/libmozqcms.a
/mnt/video/tmp_portage/portage/www-client/firefox-10.0.1/work/mozilla-release/obj-i686-pc-linux-gnu/dist/lib/libjs_static.a
-lffi   -Wl,-R/usr/lib -L/usr/lib -lssl3 -lsmime3 -lnss3 -lnssutil3
-lcrmf -lcairo -lpixman-1 -lfreetype -lfontconfig    -L/usr/lib
-lXrender -lcairo -lX11   ../../gfx/harfbuzz/src/libmozharfbuzz.a
../../gfx/ots/src/libmozots.a  ../../dist/lib/libmozsqlite3.a  -lz
-lhunspell-1.3   -L/usr/lib -levent -L/usr/lib -lvpx -lasound
-L../../dist/bin -L../../dist/lib  -Wl,-R/usr/lib -L/usr/lib -lplds4
-lplc4 -lnspr4 -lpthread -ldl ../../dist/lib/libmozalloc.a -pthread
-ldbus-glib-1 -ldbus-1 -lpthread -lgobject-2.0 -lgthread-2.0 -lrt
-lglib-2.0   -L/usr/lib -lX11  -lXext  -pthread -lpangof
t2-1.0 -lfreetype -lfontconfig -lpangocairo-1.0 -lpango-1.0 -lcairo
-lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0   -pthread
-lgtk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lfreetype
-lfontconfig -lgdk-x11-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0
-lpango-1.0 -lcairo -lgmodule-2.0 -lgobject-2.0 -lgthread-2.0 -lrt
-lglib-2.0   -lXt -lgthread-2.0 -lfreetype -lz -lbz2
-lstartup-notification-1   -ldl  -lrt
collect2: ld terminated with signal 9 [Killed]
make[5]: *** [libxul.so] Error 1
make[5]: Leaving directory
`/mnt/video/tmp_portage/portage/www-client/firefox-10.0.1/work/mozilla-release/obj-i686-pc-linux-gnu/toolkit/library'
make[4]: *** [libs_tier_platform] Error 2
make[4]: Leaving directory
`/mnt/video/tmp_portage/portage/www-client/firefox-10.0.1/work/mozilla-release/obj-i686-pc-linux-gnu'
make[3]: *** [tier_platform] Error 2
make[3]: Leaving directory
`/mnt/video/tmp_portage/portage/www-client/firefox-10.0.1/work/mozilla-release/obj-i686-pc-linux-gnu'
make[2]: *** [default] Error 2
make[2]: Leaving directory
`/mnt/video/tmp_portage/portage/www-client/firefox-10.0.1/work/mozilla-release/obj-i686-pc-linux-gnu'
make[1]: *** [realbuild] Error 2
make[1]: Leaving directory
`/mnt/video/tmp_portage/portage/www-client/firefox-10.0.1/work/mozilla-release'
make: *** [build] Error 2
emake failed
 * ERROR: www-client/firefox-10.0.1 failed (compile phase):
 *   emake failed
 *
 * Call stack:
 *     ebuild.sh, line  85:  Called src_compile
 *   environment, line 6669:  Called die
 * The specific snippet of code:
 *           CC="$(tc-getCC)" CXX="$(tc-getCXX)" LD="$(tc-getLD)"
MOZ_MAKE_FLAGS="${MAKEOPTS}" emake -f client.mk || die "emake failed";
 *
 * If you need support, post the output of 'emerge --info
=www-client/firefox-10.0.1',
 * the complete build log and the output of 'emerge -pqv
=www-client/firefox-10.0.1'.
 * The complete build log is located at
'/var/log/portage/www-client:firefox-10.0.1:20120221-062616.log'.
 * The ebuild environment file is located at
'/mnt/video/tmp_portage/portage/www-client/firefox-10.0.1/temp/environment'.
 * S: '/mnt/video/tmp_portage/portage/www-client/firefox-10.0.1/work/mozilla-release'
====================================

I found this bug in Google:

https://bugzilla.mozilla.org/show_bug.cgi?id=643690

Has anyone come across this problem and is there a Gentoo fix other
than waiting for a new release?
-- 
Regards,
Mick

Re: [gentoo-user] Firefox-10.0.1 fails to compile on x86

[Alex Schuster]

Mick writes:

> The latest stable x86 firefox fails to compile:
[... big linking being done ...]
> collect2: ld terminated with signal 9 [Killed]
> make[5]: *** [libxul.so] Error 1
[...]

Do you have enough memory on that machine, is swap space activated? The
linking phase will need a lot of memory. Although I don't understand why
ld would terminate with signal 9 then.

> I found this bug in Google:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=643690

I'm not so sure this is related.

	Wonko

[gentoo-user] Re: Firefox-10.0.1 fails to compile on x86

[Nikos Chantziaras]

On 22/02/12 00:34, Alex Schuster wrote:
> Mick writes:
>
>> The latest stable x86 firefox fails to compile:
> [... big linking being done ...]
>> collect2: ld terminated with signal 9 [Killed]
>> make[5]: *** [libxul.so] Error 1
> [...]
>
> Do you have enough memory on that machine, is swap space activated? The
> linking phase will need a lot of memory. Although I don't understand why
> ld would terminate with signal 9 then.

When there's not enough memory available, signal 9 is actually how the 
system recovers from that, by killing the offending process.

dmesg should have given a clue about what happened in that case.

Re: [gentoo-user] Re: Firefox-10.0.1 fails to compile on x86

[Philip Webb]

120222 Nikos Chantziaras wrote:
> On 22/02/12 00:34, Alex Schuster wrote:
>> Mick writes:
>>> The latest stable x86 firefox fails to compile:
>> [... big linking being done ...]
>>> collect2: ld terminated with signal 9 [Killed]
>>> make[5]: *** [libxul.so] Error 1
>> [...]
>> Do you have enough memory on that machine, is swap space activated?
>> The linking phase will need a lot of memory.
>> Although I don't understand why ld would terminate with signal 9 then.
> When there's not enough memory available, signal 9 is actually
> how the system recovers from that, by killing the offending process.
> dmesg should have given a clue about what happened in that case.

I compiled FF 10.0.1 on amd64 without any problems :
it needed  3,61 GB  disk space for the link stage
& most/all of my  2 GB  memory.

-- 
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca

[gentoo-user] Re: Firefox-10.0.1 fails to compile on x86

[walt]

On 02/21/2012 02:03 PM, Mick wrote:
> Hi All,
> 
> The latest stable x86 firefox fails to compile:
> ====================================
> www-client/firefox-10.0.1/work/mozilla-release

I noticed that firefox-bin (I got sick of compiling the damned thing every
two weeks) just updated this morning to 10.0.2, so I'd be tempted to wait
a few days until the compile-it-yourself version catches up.

Re: [gentoo-user] Re: Firefox-10.0.1 fails to compile on x86

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1408 bytes --]

On Wednesday 22 Feb 2012 00:22:27 Philip Webb wrote:
> 120222 Nikos Chantziaras wrote:
> > On 22/02/12 00:34, Alex Schuster wrote:
> >> Mick writes:
> >>> The latest stable x86 firefox fails to compile:
> >> [... big linking being done ...]
> >> 
> >>> collect2: ld terminated with signal 9 [Killed]
> >>> make[5]: *** [libxul.so] Error 1
> >> 
> >> [...]
> >> Do you have enough memory on that machine, is swap space activated?
> >> The linking phase will need a lot of memory.
> >> Although I don't understand why ld would terminate with signal 9 then.
> > 
> > When there's not enough memory available, signal 9 is actually
> > how the system recovers from that, by killing the offending process.
> > dmesg should have given a clue about what happened in that case.
> 
> I compiled FF 10.0.1 on amd64 without any problems :
> it needed  3,61 GB  disk space for the link stage
> & most/all of my  2 GB  memory.

Thanks guys, I did add half a gig of swap just in case to the 250M already 
available.  It may be that this old box is now soooo old that I can no longer 
emerge FF on it.  I will try adding some more swap (which of course will take 
away available disk space for /var/portage) and see what I run out of.

PS.  I was expecting some message on screen saying "no space left on device", 
but have not checked dmesg for running out memory errors.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-user] Re: Firefox-10.0.1 fails to compile on x86

[»Q«]

On Tue, 21 Feb 2012 17:11:31 -0800
walt <w41ter@gmail.com> wrote:

> On 02/21/2012 02:03 PM, Mick wrote:
> > Hi All,
> > 
> > The latest stable x86 firefox fails to compile:
> > ====================================
> > www-client/firefox-10.0.1/work/mozilla-release  
> 
> I noticed that firefox-bin (I got sick of compiling the damned thing
> every two weeks) just updated this morning to 10.0.2, so I'd be
> tempted to wait a few days until the compile-it-yourself version
> catches up.

I doubt there will be one until at least 10.0.3.  Firefox 10.0.2 was
released because of a security bug in <media-libs/libpng-1.5.9, and
1.5.9 has been stable a couple of days already.

Re: [gentoo-user] Re: Firefox-10.0.1 fails to compile on x86

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1661 bytes --]

On Wednesday 22 Feb 2012 07:11:15 Mick wrote:
> On Wednesday 22 Feb 2012 00:22:27 Philip Webb wrote:
> > 120222 Nikos Chantziaras wrote:
> > > On 22/02/12 00:34, Alex Schuster wrote:
> > >> Mick writes:
> > >>> The latest stable x86 firefox fails to compile:
> > >> [... big linking being done ...]
> > >> 
> > >>> collect2: ld terminated with signal 9 [Killed]
> > >>> make[5]: *** [libxul.so] Error 1
> > >> 
> > >> [...]
> > >> Do you have enough memory on that machine, is swap space activated?
> > >> The linking phase will need a lot of memory.
> > >> Although I don't understand why ld would terminate with signal 9 then.
> > > 
> > > When there's not enough memory available, signal 9 is actually
> > > how the system recovers from that, by killing the offending process.
> > > dmesg should have given a clue about what happened in that case.
> > 
> > I compiled FF 10.0.1 on amd64 without any problems :
> > it needed  3,61 GB  disk space for the link stage
> > & most/all of my  2 GB  memory.
> 
> Thanks guys, I did add half a gig of swap just in case to the 250M already
> available.  It may be that this old box is now soooo old that I can no
> longer emerge FF on it.  I will try adding some more swap (which of course
> will take away available disk space for /var/portage) and see what I run
> out of.
> 
> PS.  I was expecting some message on screen saying "no space left on
> device", but have not checked dmesg for running out memory errors.

I increased the swap to 1G and emerged without memory errors this time.  I'll 
remember to check dmesg first next time I emerge a big package.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Firefox-10.0.1 fails to compile on x86

[Willie WY Wong]

On Tue, Feb 21, 2012 at 07:22:27PM -0500, Penguin Lover Philip Webb squawked:
> I compiled FF 10.0.1 on amd64 without any problems :
> it needed  3,61 GB  disk space for the link stage
> & most/all of my  2 GB  memory.

Argh. 3.6 diskspace and 2G memory? I guess it is finally getting to
the point that my laptop cannot build firefox. Time to switch to the
-bin I guess. 

W
-- 
Data aequatione quotcunque fluentes quantitae involvente fluxiones invenire 
         et vice versa   ~~~  I. Newton

Re: [gentoo-user] Re: Firefox-10.0.1 fails to compile on x86

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 816 bytes --]

On Thursday 23 Feb 2012 10:22:40 Willie WY Wong wrote:
> On Tue, Feb 21, 2012 at 07:22:27PM -0500, Penguin Lover Philip Webb 
squawked:
> > I compiled FF 10.0.1 on amd64 without any problems :
> > it needed  3,61 GB  disk space for the link stage
> > & most/all of my  2 GB  memory.
> 
> Argh. 3.6 diskspace and 2G memory? I guess it is finally getting to
> the point that my laptop cannot build firefox. Time to switch to the
> -bin I guess.

I've only got something like 625M RAM and around 4G disk space (for 
var/portage).  I used 750M from that 4G for adding swap.  Eventually FF 
compiled fine.

The irony is that older boxen which would benefit most from building from 
source are constrained in resources to achieve this and have to resort to 
installing bin packages.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Firefox-10.0.1 fails to compile on x86

[Philip Webb]

120223 Willie WY Wong wrote:
> On Tue, Feb 21, 2012 at 07:22:27PM -0500, Penguin Lover Philip Webb squawked:
>> I compiled FF 10.0.1 on amd64 without any problems :
>> it needed  3,61 GB  disk space for the link stage
>> & most/all of my  2 GB  memory.
> Argh. 3.6 diskspace and 2G memory?
> I guess it is finally getting to the point
> that my laptop cannot build firefox. Time to switch to the -bin I guess. 

I installed Midori in my netbook ( 1 GB  memory,  160 GB  disk)
& have replacements for all the KDE apps I use on my desktop;
I use Fluxbox to manage everything on both.

-- 
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca

Re: [gentoo-user] Re: Firefox-10.0.1 fails to compile on x86

[Walter Dnes]

On Thu, Feb 23, 2012 at 10:44:36AM +0000, Mick wrote

> I've only got something like 625M RAM and around 4G disk space (for 
> var/portage).  I used 750M from that 4G for adding swap.  Eventually FF 
> compiled fine.
> 
> The irony is that older boxen which would benefit most from building from 
> source are constrained in resources to achieve this and have to resort to 
> installing bin packages.

  An external USB drive, with appropriate changes in /etc/make.conf,
plus an overnight build run might be the answer.

  Also, I'm trying www-client/midori as a browser.  It's based on
webkit, like most Android browsers.  Still a bit rough around the edges.

-- 
Walter Dnes <waltdnes@waltdnes.org>

[gentoo-user] Re: Firefox-10.0.1 fails to compile on x86

[Nikos Chantziaras]

On 23/02/12 12:44, Mick wrote:
> On Thursday 23 Feb 2012 10:22:40 Willie WY Wong wrote:
>> On Tue, Feb 21, 2012 at 07:22:27PM -0500, Penguin Lover Philip Webb
> squawked:
>>> I compiled FF 10.0.1 on amd64 without any problems :
>>> it needed  3,61 GB  disk space for the link stage
>>> &  most/all of my  2 GB  memory.
>>
>> Argh. 3.6 diskspace and 2G memory? I guess it is finally getting to
>> the point that my laptop cannot build firefox. Time to switch to the
>> -bin I guess.
>
> I've only got something like 625M RAM and around 4G disk space (for
> var/portage).  I used 750M from that 4G for adding swap.  Eventually FF
> compiled fine.
>
> The irony is that older boxen which would benefit most from building from
> source are constrained in resources to achieve this and have to resort to
> installing bin packages.

I doubt that the bin package will be slower than the one compiled from 
source.  I predict the reverse, in fact.  The bin package will perform 
better.

Why don't you test it with an online browser benchmark?  You can 
quickpkg the current installed version, emerge the -bin version.  You 
can later emerge -C the -bin version and emerge -K the one you quickpkg'ed.

Re: [gentoo-user] Re: Firefox-10.0.1 fails to compile on x86

[Michael Mol]

On Thu, Feb 23, 2012 at 2:36 PM, Nikos Chantziaras <realnc@arcor.de> wrote:
> On 23/02/12 12:44, Mick wrote:
>>
>> On Thursday 23 Feb 2012 10:22:40 Willie WY Wong wrote:
>>>
>>> On Tue, Feb 21, 2012 at 07:22:27PM -0500, Penguin Lover Philip Webb
>>
>> squawked:
>>>>
>>>> I compiled FF 10.0.1 on amd64 without any problems :
>>>> it needed  3,61 GB  disk space for the link stage
>>>> &  most/all of my  2 GB  memory.
>>>
>>>
>>> Argh. 3.6 diskspace and 2G memory? I guess it is finally getting to
>>> the point that my laptop cannot build firefox. Time to switch to the
>>> -bin I guess.
>>
>>
>> I've only got something like 625M RAM and around 4G disk space (for
>> var/portage).  I used 750M from that 4G for adding swap.  Eventually FF
>> compiled fine.
>>
>> The irony is that older boxen which would benefit most from building from
>> source are constrained in resources to achieve this and have to resort to
>> installing bin packages.
>
>
> I doubt that the bin package will be slower than the one compiled from
> source.  I predict the reverse, in fact.  The bin package will perform
> better.

That seems a strange prediction. What drives that hunch?

-- 
:wq

[gentoo-user] Re: Firefox-10.0.1 fails to compile on x86

[Nikos Chantziaras]

On 23/02/12 21:42, Michael Mol wrote:
> On Thu, Feb 23, 2012 at 2:36 PM, Nikos Chantziaras<realnc@arcor.de>  wrote:
>> On 23/02/12 12:44, Mick wrote:
>>> The irony is that older boxen which would benefit most from building from
>>> source are constrained in resources to achieve this and have to resort to
>>> installing bin packages.
>>
>> I doubt that the bin package will be slower than the one compiled from
>> source.  I predict the reverse, in fact.  The bin package will perform
>> better.
>
> That seems a strange prediction. What drives that hunch?

The PGO optimized build that Mozilla is shipping.  You can also build 
with PGO from source, but that means building FF *twice* in a row (by 
enabling the "pgo" USE flag).  I doubt that with the old laptop anyone 
is building FF twice with PGO, and that means that the -bin package 
should be faster.

Furthermore, FF is build using its own CFLAGS.  They are the same in the 
source build as well as in the -bin package.  The only difference is 
probably the -march option.  And that doesn't make much difference to 
begin with (after -march=i686, gains are very minimal).

Re: [gentoo-user] Re: Firefox-10.0.1 fails to compile on x86

[Dale]

Nikos Chantziaras wrote:
> On 23/02/12 12:44, Mick wrote:
>> On Thursday 23 Feb 2012 10:22:40 Willie WY Wong wrote:
>>> On Tue, Feb 21, 2012 at 07:22:27PM -0500, Penguin Lover Philip Webb
>> squawked:
>>>> I compiled FF 10.0.1 on amd64 without any problems :
>>>> it needed  3,61 GB  disk space for the link stage
>>>> &  most/all of my  2 GB  memory.
>>>
>>> Argh. 3.6 diskspace and 2G memory? I guess it is finally getting to
>>> the point that my laptop cannot build firefox. Time to switch to the
>>> -bin I guess.
>>
>> I've only got something like 625M RAM and around 4G disk space (for
>> var/portage).  I used 750M from that 4G for adding swap.  Eventually FF
>> compiled fine.
>>
>> The irony is that older boxen which would benefit most from building from
>> source are constrained in resources to achieve this and have to resort to
>> installing bin packages.
> 
> I doubt that the bin package will be slower than the one compiled from
> source.  I predict the reverse, in fact.  The bin package will perform
> better.
> 
> Why don't you test it with an online browser benchmark?  You can
> quickpkg the current installed version, emerge the -bin version.  You
> can later emerge -C the -bin version and emerge -K the one you quickpkg'ed.
> 
> 
> 


I try to avoid pre-compiled software for the opposite reason of what you
think.  What makes you think that software designed and compiled to
utilize all the good parts of my system would run slower than a software
designed to run on any CPU/hardware out there?  This is the first time I
ever saw anyone make this claim.  Can you shed some light on this?

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

[gentoo-user] Re: Firefox-10.0.1 fails to compile on x86

[Nikos Chantziaras]

On 23/02/12 22:11, Dale wrote:
> Nikos Chantziaras wrote:
>> On 23/02/12 12:44, Mick wrote:
>>> On Thursday 23 Feb 2012 10:22:40 Willie WY Wong wrote:
>>>
>>> The irony is that older boxen which would benefit most from building from
>>> source are constrained in resources to achieve this and have to resort to
>>> installing bin packages.
>>
>> I doubt that the bin package will be slower than the one compiled from
>> source.  I predict the reverse, in fact.  The bin package will perform
>> better.
>>
>> Why don't you test it with an online browser benchmark?  You can
>> quickpkg the current installed version, emerge the -bin version.  You
>> can later emerge -C the -bin version and emerge -K the one you quickpkg'ed.
>
> I try to avoid pre-compiled software for the opposite reason of what you
> think.  What makes you think that software designed and compiled to
> utilize all the good parts of my system would run slower than a software
> designed to run on any CPU/hardware out there?  This is the first time I
> ever saw anyone make this claim.  Can you shed some light on this?

Already did in my other post.

Also, your assumption is wrong.  Binary packages are not designed to run 
on any CPU and hardware out there.  They are designed to run on specific 
architectures, and with a minimum requirement of some specific CPU. 
firefox-bin will certainly not run on a PPC or MIPS machine running 
Linux, for example.

Re: [gentoo-user] Re: Firefox-10.0.1 fails to compile on x86

[Willie WY Wong]

On Thu, Feb 23, 2012 at 09:55:07PM +0200, Penguin Lover Nikos Chantziaras squawked:
> The PGO optimized build that Mozilla is shipping.  You can also build 
> with PGO from source, but that means building FF *twice* in a row (by 
> enabling the "pgo" USE flag).  I doubt that with the old laptop anyone 
> is building FF twice with PGO, and that means that the -bin package 
> should be faster.

Call me a sadist, but on my netbook I did build FF with +pgo. 

I figured, if I was going to let it build overnight and more, why not?
:)
(FWIW, it took 7hrs and 40 minutes to build FF8.)

W

-- 
Data aequatione quotcunque fluentes quantitae involvente fluxiones invenire 
         et vice versa   ~~~  I. Newton

[gentoo-user] Re: Firefox-10.0.1 fails to compile on x86

[Nikos Chantziaras]

On 23/02/12 22:24, Willie WY Wong wrote:
> On Thu, Feb 23, 2012 at 09:55:07PM +0200, Penguin Lover Nikos Chantziaras squawked:
>> The PGO optimized build that Mozilla is shipping.  You can also build
>> with PGO from source, but that means building FF *twice* in a row (by
>> enabling the "pgo" USE flag).  I doubt that with the old laptop anyone
>> is building FF twice with PGO, and that means that the -bin package
>> should be faster.
>
> Call me a sadist, but on my netbook I did build FF with +pgo.
>
> I figured, if I was going to let it build overnight and more, why not?
> :)

If you think it's worth the hassle, why not.  Personally, the only 
reason I would build from source on such a slow system is to get a 
64-bit build, since the -bin package seems to be 32-bit.  That means the 
GUI is going to look like ass on AMD64 (due to lack of 32-bit versions 
of the Gtk theme engines.)

If you're on 32-bit to begin with, and you're building with "pgo" 
enabled, then my guess is that the performance compared to the -bin 
package is about the same.  But as I said previously, this can be easily 
tested by running a browser benchmark, such as this:

   http://krakenbenchmark.mozilla.org

You could compare the results of the -bin package vs your self-compiled one.

Re: [gentoo-user] Re: Firefox-10.0.1 fails to compile on x86

[Michael Mol]

On Thu, Feb 23, 2012 at 2:55 PM, Nikos Chantziaras <realnc@arcor.de> wrote:
> On 23/02/12 21:42, Michael Mol wrote:
>>
>> On Thu, Feb 23, 2012 at 2:36 PM, Nikos Chantziaras<realnc@arcor.de>
>>  wrote:
>>>
>>> On 23/02/12 12:44, Mick wrote:
>>>>
>>>> The irony is that older boxen which would benefit most from building
>>>> from
>>>> source are constrained in resources to achieve this and have to resort
>>>> to
>>>> installing bin packages.
>>>
>>>
>>> I doubt that the bin package will be slower than the one compiled from
>>> source.  I predict the reverse, in fact.  The bin package will perform
>>> better.
>>
>>
>> That seems a strange prediction. What drives that hunch?
>
>
> The PGO optimized build that Mozilla is shipping.  You can also build with
> PGO from source, but that means building FF *twice* in a row (by enabling
> the "pgo" USE flag).  I doubt that with the old laptop anyone is building FF
> twice with PGO, and that means that the -bin package should be faster.
>
> Furthermore, FF is build using its own CFLAGS.  They are the same in the
> source build as well as in the -bin package.  The only difference is
> probably the -march option.  And that doesn't make much difference to begin
> with (after -march=i686, gains are very minimal).

I knew and forgot about PGO, but I didn't realize there was a USE flag
for it. Neat. I'll be enabling that.

I disagree with the idea that keeping things down around -march=i686
provides only minimal gains. SSE and SSE2 instructions carry a big
benefit for numerical operations, especially those which can be
parallelized, but not enough to justify batching into a GPU. AVX will
be adding operations which allow more useful and flexible use of
registers. Simply bumping up to x86-64 from simple x86 doubles your
GPRs, which gives the compiler all kinds of room to work with.

If the combination of those things doesn't significantly benefit a
program written in C or C++, then I suspect there's something
dreadfully wrong with the architecture of that codebase.


-- 
:wq

Re: [gentoo-user] Re: Firefox-10.0.1 fails to compile on x86

[Willie WY Wong]

On Thu, Feb 23, 2012 at 10:43:47PM +0200, Penguin Lover Nikos Chantziaras squawked:
> If you think it's worth the hassle, why not.  Personally, the only 
> reason I would build from source on such a slow system is to get a 
> 64-bit build, since the -bin package seems to be 32-bit.  That means the 
> GUI is going to look like ass on AMD64 (due to lack of 32-bit versions 
> of the Gtk theme engines.)

Actually, why is it that upstream does not provide 64bit binaries? (It
always bothers me to see my wife's Windows 7 machines running a copy
of firefox marked, in parenthesis, 32 bit.)

> If you're on 32-bit to begin with, and you're building with "pgo" 
> enabled, then my guess is that the performance compared to the -bin 
> package is about the same.  But as I said previously, this can be easily 
> tested by running a browser benchmark, such as this:
> 
>    http://krakenbenchmark.mozilla.org
> 
> You could compare the results of the -bin package vs your self-compiled one.

I should definitely do that. 

W
-- 
Data aequatione quotcunque fluentes quantitae involvente fluxiones invenire 
         et vice versa   ~~~  I. Newton

Re: [gentoo-user] Re: Firefox-10.0.1 fails to compile on x86

[Paul Hartman]

On Thu, Feb 23, 2012 at 4:21 PM, Willie WY Wong <wongwwy@member.ams.org> wrote:
> Actually, why is it that upstream does not provide 64bit binaries? (It
> always bothers me to see my wife's Windows 7 machines running a copy
> of firefox marked, in parenthesis, 32 bit.)

They're working on it... They actually have started generating 64-bit
nightly builds for Windows and Linux:
https://nightly.mozilla.org/

If I had to guess what the hold-up has been:

User confusion about which version to use (32-bit will work for
everyone, 64-bit won't)
Plugin availability (even Adobe and Sun didn't make 64-bit flash or
java until recently)

Re: [gentoo-user] Re: Firefox-10.0.1 fails to compile on x86

[Paul Hartman]

On Thu, Feb 23, 2012 at 4:43 PM, Paul Hartman
<paul.hartman+gentoo@gmail.com> wrote:
> (32-bit will work for
> everyone, 64-bit won't)

And of course by "everyone" I'm talking about Windows or Ubuntu users
who download binaries from mozilla.org in the first place, not
sophisticated pure-64-bit Gentoo users. ;)

[gentoo-user] Re: Firefox-10.0.1 fails to compile on x86

[Dale]

Nikos Chantziaras wrote:
> On 23/02/12 22:11, Dale wrote:
>> Nikos Chantziaras wrote:
>>> On 23/02/12 12:44, Mick wrote:
>>>> On Thursday 23 Feb 2012 10:22:40 Willie WY Wong wrote:
>>>>
>>>> The irony is that older boxen which would benefit most from building
>>>> from
>>>> source are constrained in resources to achieve this and have to
>>>> resort to
>>>> installing bin packages.
>>>
>>> I doubt that the bin package will be slower than the one compiled from
>>> source.  I predict the reverse, in fact.  The bin package will perform
>>> better.
>>>
>>> Why don't you test it with an online browser benchmark?  You can
>>> quickpkg the current installed version, emerge the -bin version.  You
>>> can later emerge -C the -bin version and emerge -K the one you
>>> quickpkg'ed.
>>
>> I try to avoid pre-compiled software for the opposite reason of what you
>> think.  What makes you think that software designed and compiled to
>> utilize all the good parts of my system would run slower than a software
>> designed to run on any CPU/hardware out there?  This is the first time I
>> ever saw anyone make this claim.  Can you shed some light on this?
> 
> Already did in my other post.
> 
> Also, your assumption is wrong.  Binary packages are not designed to run
> on any CPU and hardware out there.  They are designed to run on specific
> architectures, and with a minimum requirement of some specific CPU.
> firefox-bin will certainly not run on a PPC or MIPS machine running
> Linux, for example.
> 
> 
> 


Actually, I can install the same binaries on a AMD machine, a Intel
based machine and they work.  Thing is, on my machine, I enable
MARCH=native and everything is compiled for my CPU.  Since I have AMD,
they may not run or may be buggy if ran on a Intel machine.  That's what
I have always been told.  Have I been told the wrong thing for the last
8 or 9 years?

Am I right in reading as the rest is Firefox specific?

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

[gentoo-user] Re: Firefox-10.0.1 fails to compile on x86

[Nikos Chantziaras]

On 24/02/12 02:34, Dale wrote:
> Nikos Chantziaras wrote:
>> On 23/02/12 22:11, Dale wrote:
>>> Nikos Chantziaras wrote:
>>>> On 23/02/12 12:44, Mick wrote:
>>>>> On Thursday 23 Feb 2012 10:22:40 Willie WY Wong wrote:
>>>>>
>>>>> The irony is that older boxen which would benefit most from building
>>>>> from
>>>>> source are constrained in resources to achieve this and have to
>>>>> resort to
>>>>> installing bin packages.
>>>>
>>>> I doubt that the bin package will be slower than the one compiled from
>>>> source.  I predict the reverse, in fact.  The bin package will perform
>>>> better.
>>>>
>>>> Why don't you test it with an online browser benchmark?  You can
>>>> quickpkg the current installed version, emerge the -bin version.  You
>>>> can later emerge -C the -bin version and emerge -K the one you
>>>> quickpkg'ed.
>>>
>>> I try to avoid pre-compiled software for the opposite reason of what you
>>> think.  What makes you think that software designed and compiled to
>>> utilize all the good parts of my system would run slower than a software
>>> designed to run on any CPU/hardware out there?  This is the first time I
>>> ever saw anyone make this claim.  Can you shed some light on this?
>>
>> Already did in my other post.
>>
>> Also, your assumption is wrong.  Binary packages are not designed to run
>> on any CPU and hardware out there.  They are designed to run on specific
>> architectures, and with a minimum requirement of some specific CPU.
>> firefox-bin will certainly not run on a PPC or MIPS machine running
>> Linux, for example.
>>
>>
>>
>
>
> Actually, I can install the same binaries on a AMD machine, a Intel
> based machine and they work.  Thing is, on my machine, I enable
> MARCH=native and everything is compiled for my CPU.  Since I have AMD,
> they may not run or may be buggy if ran on a Intel machine.  That's what
> I have always been told.  Have I been told the wrong thing for the last
> 8 or 9 years?

AMD and Intel are the same architecture: Intel.  AMD makes 
Intel-compatible CPUs.  Furthermore, the binary Mozilla provides 
requires targets a subset of CPUs; it certainly won't run on an 80386.

The speed gains of building for specific submodels of CPUs might be 
there, but they're minimal.  Benchmarks have shown (can't find the 
article, it was on Phoronix) that after -march=i686 you get diminishing 
returns.

[gentoo-user] Re: Firefox-10.0.1 fails to compile on x86

[»Q«]

On Thu, 23 Feb 2012 16:43:11 -0600
Paul Hartman <paul.hartman+gentoo@gmail.com> wrote:

> On Thu, Feb 23, 2012 at 4:21 PM, Willie WY Wong
> <wongwwy@member.ams.org> wrote:
> > Actually, why is it that upstream does not provide 64bit binaries?
> > (It always bothers me to see my wife's Windows 7 machines running a
> > copy of firefox marked, in parenthesis, 32 bit.)
> 
> They're working on it... They actually have started generating 64-bit
> nightly builds for Windows and Linux:
> https://nightly.mozilla.org/
> 
> If I had to guess what the hold-up has been:
> 
> User confusion about which version to use (32-bit will work for
> everyone, 64-bit won't)
> Plugin availability (even Adobe and Sun didn't make 64-bit flash or
> java until recently)

It's mostly that their build people have had more important stuff to
deal with for a while, such as adjusting their system to deal with the
new-ish release cycle and giving their devs more a more flexible system
for building testing binaries.  (And there's been almost no clamor from
the Windows world for 64-bit builds.  For people who are clamoring,
there's a third-party build called Waterfox.)

But I thought they do release 64-bit binaries for Linux.  There's a
linux-x86_64 directory in their stable release directory, 
<ftp://releases.mozilla.org/pub/mozilla.org/firefox/releases/latest/>.

Re: [gentoo-user] Re: Firefox-10.0.1 fails to compile on x86

[Walter Dnes]

On Fri, Feb 24, 2012 at 03:13:07AM +0200, Nikos Chantziaras wrote

> The speed gains of building for specific submodels of CPUs might
> be there, but they're minimal.  Benchmarks have shown (can't find
> the article, it was on Phoronix) that after -march=i686 you get
> diminishing returns.

  In that case, the benchmarks are useless.  From my personal
experience...  a fresh i686 install on a 4 and 1/2 year old Dell with
onboard Intel GPU was not able to keep up with the slowest available
speed on NHL Gamecenter Live.  Ditto for 1080i TV from my HDHomerun
tuner box.  After rebuilding system+world+kernel with "march=native",
it works just fine for the above tasks.  I'm not the only one to see
this.  See thread...
"Slow not in sync movie playing with mplayer2, ffmpeg, x264 with intel core i5"
starting Sun, 12 Feb 2012 on this list.

  As I mentioned in that thread
> Optimizing one library may seem very minor, but it all adds up when
> you optimize every library on your system.

  To get the full benefit of optimization, you need to optimize your
entire system.  The i686 code used for the install CD has to be generic
lowest-common-denominator i686 code, in order to run on every 6-year-old
i686 cpu out there.  The tradeoff is that you lose the benefits of
optimisation.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-user] Re: Firefox-10.0.1 fails to compile on x86

[Adam Carter]

On Sat, Feb 25, 2012 at 5:22 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Fri, Feb 24, 2012 at 03:13:07AM +0200, Nikos Chantziaras wrote
>
>> The speed gains of building for specific submodels of CPUs might
>> be there, but they're minimal.  Benchmarks have shown (can't find
>> the article, it was on Phoronix) that after -march=i686 you get
>> diminishing returns.
>
>  In that case, the benchmarks are useless.  From my personal
> experience...  a fresh i686 install on a 4 and 1/2 year old Dell with
> onboard Intel GPU was not able to keep up with the slowest available
> speed on NHL Gamecenter Live.  Ditto for 1080i TV from my HDHomerun
> tuner box.  After rebuilding system+world+kernel with "march=native",
> it works just fine for the above tasks.

Playing video is one of few situations in which optimisation makes a
lot of difference though, thanks to the mmx/sse stuff, which is post
i686. So a video benchmark will should show that up, but the boost may
be lost in a more general suite of weighted benchmarks.

Also, different versions of gcc optimise differently. Usually the
optimisation gets better but there a quite a few cases where
performance regresses.

Re: [gentoo-user] Re: Firefox-10.0.1 fails to compile on x86

[Dale]

Walter Dnes wrote:
> On Fri, Feb 24, 2012 at 03:13:07AM +0200, Nikos Chantziaras wrote
> 
>> The speed gains of building for specific submodels of CPUs might
>> be there, but they're minimal.  Benchmarks have shown (can't find
>> the article, it was on Phoronix) that after -march=i686 you get
>> diminishing returns.
> 
>   In that case, the benchmarks are useless.  From my personal
> experience...  a fresh i686 install on a 4 and 1/2 year old Dell with
> onboard Intel GPU was not able to keep up with the slowest available
> speed on NHL Gamecenter Live.  Ditto for 1080i TV from my HDHomerun
> tuner box.  After rebuilding system+world+kernel with "march=native",
> it works just fine for the above tasks.  I'm not the only one to see
> this.  See thread...
> "Slow not in sync movie playing with mplayer2, ffmpeg, x264 with intel core i5"
> starting Sun, 12 Feb 2012 on this list.
> 
>   As I mentioned in that thread
>> Optimizing one library may seem very minor, but it all adds up when
>> you optimize every library on your system.
> 
>   To get the full benefit of optimization, you need to optimize your
> entire system.  The i686 code used for the install CD has to be generic
> lowest-common-denominator i686 code, in order to run on every 6-year-old
> i686 cpu out there.  The tradeoff is that you lose the benefits of
> optimisation.
> 


It's odd that I was thinking about your video problem when I posted my
reply earlier.

If using those makes no difference, why even have the option?

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

[gentoo-user] Re: Firefox-10.0.1 fails to compile on x86

[Nikos Chantziaras]

On 25/02/12 13:43, Dale wrote:
> Walter Dnes wrote:
>>    In that case, the benchmarks are useless.  From my personal
>> experience...  a fresh i686 install on a 4 and 1/2 year old Dell with
>> onboard Intel GPU was not able to keep up with the slowest available
>> speed on NHL Gamecenter Live.  Ditto for 1080i TV from my HDHomerun
>> tuner box.  After rebuilding system+world+kernel with "march=native",
>> it works just fine for the above tasks.  I'm not the only one to see
>> this.  See thread...
>
> It's odd that I was thinking about your video problem when I posted my
> reply earlier.
>
> If using those makes no difference, why even have the option?

I was talking about Firefox though, which was what this thread is about :-P

Re: [gentoo-user] Re: Firefox-10.0.1 fails to compile on x86

[Dale]

Nikos Chantziaras wrote:
> On 25/02/12 13:43, Dale wrote:
>> Walter Dnes wrote:
>>>    In that case, the benchmarks are useless.  From my personal
>>> experience...  a fresh i686 install on a 4 and 1/2 year old Dell with
>>> onboard Intel GPU was not able to keep up with the slowest available
>>> speed on NHL Gamecenter Live.  Ditto for 1080i TV from my HDHomerun
>>> tuner box.  After rebuilding system+world+kernel with "march=native",
>>> it works just fine for the above tasks.  I'm not the only one to see
>>> this.  See thread...
>>
>> It's odd that I was thinking about your video problem when I posted my
>> reply earlier.
>>
>> If using those makes no difference, why even have the option?
> 
> I was talking about Firefox though, which was what this thread is about :-P
> 
> 
> 

But one could read that as for all software.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

Re: [gentoo-user] Re: Firefox-10.0.1 fails to compile on x86

[Walter Dnes]

On Sat, Feb 25, 2012 at 10:30:21PM +1100, Adam Carter wrote

> Playing video is one of few situations in which optimisation makes a
> lot of difference though, thanks to the mmx/sse stuff, which is post
> i686. So a video benchmark will should show that up, but the boost may
> be lost in a more general suite of weighted benchmarks.

  Today's web is heavily multimedia.  There are some text-oriented
websites where w3m or links is sufficient, but they're few and far
between.  And as I mentioned earlier, the appropriate comparison is
between a fully optimised system versus a fully default system, dual
booting on the same machine to eliminate hardware biases.  Linux
works with libraries.  Firefox calls a lotlibraries, which call other
libraries and the kernel, too.  That's why it has be the entire system
being optimized.

> Also, different versions of gcc optimise differently. Usually the
> optimisation gets better but there a quite a few cases where
> performance regresses.

  ???  Can you name any cases where "-march=native" is worse than than
the default i686 build?  And please do an apples-to-apples comparison.
I.e. pgo bin versus pgo build from source.

-- 
Walter Dnes <waltdnes@waltdnes.org>