Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 11 Feb 2010 18:54:43 +0100
From:      daniele <meslists@yahoo.fr>
To:        freebsd-gecko@freebsd.org
Subject:   firefox 3.6 builds now - temporary fix - (also) a note (also) for maintainers
Message-ID:  <4B744463.3040007@yahoo.fr>

next in thread | raw e-mail | index | archive | help
Hi all,


some days ago I wrote on this list about a stop in making firefox 3.6 on
my pc system

> http://lists.freebsd.org/pipermail/freebsd-gecko/2010-February/000682.html

Maybe someone read about it but at the moment of writing I received no 
feedback. This is why I am sending now some result I got after some tests.

.....1 - The result

After some little modifications I could finally build and install the 
port. It seems it is working fine

.....2 - The problems I encountered & The temporary fixes

First problem was c++ being killed when the swap partition was 
(completely) filled up by the process and the process was requesting 
more swap space

> swap_pager_getswapspace(4): failed pid 37019 (cc1plus), uid 0, was
> killed: out of swap spaceOn 02/11/2010 16:28,

The command being executed was this one

> c++ -o nsHtml5ElementName.o -c -I../../dist/system_wrappers -include
> ../../config/gcc_hidden.h -DMOZILLA_INTERNAL_API -D_IMPL_NS_COM
> -DEXPORT_XPT_API -DEXPORT_XPTC_API -D_IMPL_NS_COM_OBSOLETE
> -D_IMPL_NS_GFX -D_IMPL_NS_WIDGET -DIMPL_XREAPI -DIMPL_NS_NET
> -DIMPL_THEBES  -DOSTYPE=\"FreeBSD8\" -DOSARCH=FreeBSD  -I. -I.
> -I../../dist/include -I../../dist/include/nsprpub
> -I/usr/local/include/nspr
> -I/usr/ports/www/firefox/work/mozilla-1.9.2/dist/include/nss
> -I/usr/include   -I./../../content/base/src  -I/usr/local/include
> -fPIC  -I/usr/local/include  -I/usr/local/include -fno-rtti
> -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth
> -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align
> -Wno-invalid-offsetof -Wno-long-long -O2 -pipe -O2
> -fno-strict-aliasing -O2 -fno-strict-aliasing -fshort-wchar -pipe
> -DNDEBUG -DTRIMMED -O2  -I/usr/local/include  -I/usr/local/include
> -DMOZILLA_CLIENT -include ../../mozilla-config.h
> nsHtml5ElementName.cpp

Looking at the code one sees all these '-02'(the "level" of optimization).
Seeing that by default the code has a level of optimization "2" I 
decided to switch to level of optimization "0", that requires less 
"effort". To reach this goal I changed the original Makefile this way

> - EXTRA_CFLAGS=	-O2

> + EXTRA_CFLAGS=	-O0

After this change in the code I run make  but I still got a stop: errors 
from swap again and the command being executed was this one

> c++ -o nsHtml5ElementName.o -c -I../../dist/system_wrappers -include
>  ../../config/gcc_hidden.h -DMOZILLA_INTERNAL_API -D_IMPL_NS_COM
> -DEXPORT_XPT_API -DEXPORT_XPTC_API -D_IMPL_NS_COM_OBSOLETE
> -D_IMPL_NS_GFX -D_IMPL_NS_WIDGET -DIMPL_XREAPI -DIMPL_NS_NET
> -DIMPL_THEBES  -DOSTYPE=\"FreeBSD8\" -DOSARCH=FreeBSD  -I. -I.
> -I../../dist/include -I../../dist/include/nsprpub
> -I/usr/local/include/nspr
> -I/usr/ports/www/firefox/work/mozilla-1.9.2/dist/include/nss
> -I/usr/include   -I./../../content/base/src  -I/usr/local/include
> -fPIC  -I/usr/local/include  -I/usr/local/include -fno-rtti
> -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth
> -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align
> -Wno-invalid-offsetof -Wno-long-long -O2 -pipe -O2
> -fno-strict-aliasing -O0 -fno-strict-aliasing -fshort-wchar -pipe
> -DNDEBUG -DTRIMMED -O2  -I/usr/local/include  -I/usr/local/include
> -DMOZILLA_CLIENT -include ../../mozilla-config.h
> nsHtml5ElementName.cpp

As one can notice there are still those parameters that involve a level
2 of optimization along with my '-O0'. This is fine but the order,
relevant, is not acceptable I think. It is not acceptable because my 
"switch" "-O0", the one that I have the opportunity to modify, appears 
in the middle of those parameters. So the question is... once the job is 
done, will I get an optimized code or not ? and thus: will my pc have to 
do a little more effort or not ? According to the documentation I found 
(cc manual page) It seems that the answer to both the questions is "yes" 
in fact

> If you use multiple -O options, with or without level numbers, the
> last such option is the one that is effective.

So in my case the effective level is the 2nd, not the one I intended to 
use. And this, again, leads to a stop in the build process (on this system).

Seen that, I decided to directly issue a similar command, without all 
the '-O2', but this time trying with a '-O1'

> c++ -o nsHtml5ElementName.o -c -I../../dist/system_wrappers -include
>  ../../config/gcc_hidden.h -DMOZILLA_INTERNAL_API -D_IMPL_NS_COM
> -DEXPORT_XPT_API -DEXPORT_XPTC_API -D_IMPL_NS_COM_OBSOLETE
> -D_IMPL_NS_GFX -D_IMPL_NS_WIDGET -DIMPL_XREAPI -DIMPL_NS_NET
> -DIMPL_THEBES  -DOSTYPE=\"FreeBSD8\" -DOSARCH=FreeBSD  -I. -I.
> -I../../dist/include -I../../dist/include/nsprpub
> -I/usr/local/include/nspr
> -I/usr/ports/www/firefox/work/mozilla-1.9.2/dist/include/nss
> -I/usr/include   -I./../../content/base/src  -I/usr/local/include
> -fPIC  -I/usr/local/include  -I/usr/local/include -fno-rtti
> -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth
> -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align
> -Wno-invalid-offsetof -Wno-long-long -pipe -fno-strict-aliasing
> -fno-strict-aliasing -fshort-wchar -pipe  -DNDEBUG -DTRIMMED -O1
> -I/usr/local/include  -I/usr/local/include -DMOZILLA_CLIENT -include
>  ../../mozilla-config.h nsHtml5ElementName.cpp

It worked ! Time to restart making the build :-)

The process went on but I had a stop again when the file on hand was
"nsHtml5NamedCharacters.cpp".
Same history : I stripped all the '-O2' and this time I added a '-O0'
(dont call me stupid ! just tester ... well not stupid tester ;) )

It worked ! ...And the build run successfully until the end. Issuing
'make install' installed the port that now runs fine.

.....3 - Conclusion

To make firefox 3.6 build on those machines affected by the same
problems I encountered (caused, probably, just by the "little" (840 MB!) 
swap partition ?), I suppose that a (temporary ?) workaround would
be to correct the code that generates the previous strings in a way that 
the optimization flag chosen by the administrator, at build time, 
appears as the last optimization flag.

daniele

----
uname + Makefile ts
---
FreeBSD 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009 
root at almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386
---
$FreeBSD: ports/www/firefox/Makefile,v 1.220 2010/02/07 21:48:43 beat Exp $



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B744463.3040007>