Attached is a Firefox port modified with all the changes I intend to push into the one in opt once 2.0.0.13 is released, mostly it's further debloating for Firefox, however it also includes one change that could potentially be disruptive to users: It links all of Firefox's internal libraries and extensions statically, into the main binary. This reduces disk space consumption, improves start-time performance and doesn't break any applications that build against Firefox. Mozilla's own binary builds are built this way, in fact. The reason this could be disruptive is because the final linking to generate the main firefox-bin file requires a lot of RAM, in my experience, 512MB minimum or a large amount of swap to compensate. This could cause build problems for some users, although Danny Rawlins managed to build this port on a system with only 256MB of RAM. I wanted to post this here to receive further testing before 2.0.0.13 is released, so that I don't push something potentially destructive to opt. -- ~predatorfreak GnuPG Public key: http://pred.dcaf-security.org/dcafsec-pub-gpgkey.asc
On Mon, 3 Mar 2008 04:48:13 -0500 Brett Goulder wrote:
Attached is a Firefox port modified with all the changes I intend to push into the one in opt once 2.0.0.13 is released, mostly it's further debloating for Firefox, however it also includes one change that could potentially be disruptive to users: It links all of Firefox's internal libraries and extensions statically, into the main binary. This reduces disk space consumption, improves start-time performance and doesn't break any applications that build against Firefox. Mozilla's own binary builds are built this way, in fact.
The reason this could be disruptive is because the final linking to generate the main firefox-bin file requires a lot of RAM, in my experience, 512MB minimum or a large amount of swap to compensate. This could cause build problems for some users, although Danny Rawlins managed to build this port on a system with only 256MB of RAM.
I wanted to post this here to receive further testing before 2.0.0.13 is released, so that I don't push something potentially destructive to opt.
Sorry, forgot to attach port. -- ~predatorfreak GnuPG Public key: http://pred.dcaf-security.org/dcafsec-pub-gpgkey.asc
Brett Goulder schrieb:
Attached is a Firefox port
Hmm... didn't see any attachment here. :-(
modified with all the changes I intend to push into the one in opt once 2.0.0.13 is released, mostly it's further debloating for Firefox, however it also includes one change that could potentially be disruptive to users: It links all of Firefox's internal libraries and extensions statically, into the main binary. This reduces disk space consumption, improves start-time performance and doesn't break any applications that build against Firefox. Mozilla's own binary builds are built this way, in fact.
That makes sense to me.
The reason this could be disruptive is because the final linking to generate the main firefox-bin file requires a lot of RAM, in my experience, 512MB minimum or a large amount of swap to compensate. This could cause build problems for some users, although Danny Rawlins managed to build this port on a system with only 256MB of RAM.
I was able to build opt/firefox on embedded PowerPC with 256MB successfully. But the build doesn't run. I haven't had time to have a closer look what's happening there and I didn't tests on x86 yet. All this needs to be fixed anyway.
I wanted to post this here to receive further testing before 2.0.0.13 is released, so that I don't push something potentially destructive to opt.
Push it again or put it in your repo. And please point out where to look closely for any problems. Regards, Clemens
On Mon, 03 Mar 2008 13:32:38 +0100 Clemens Koller wrote:
Brett Goulder schrieb:
Attached is a Firefox port
Hmm... didn't see any attachment here. :-(
Sorry, I was having some problems with my mail server and by the time I fixed it, I forgot to include the attachment. I sent a reply to the mailing list about it and also sent one with the attachment, but due to the size, it got delayed for moderator approval.
modified with all the changes I intend to push into the one in opt once 2.0.0.13 is released, mostly it's further debloating for Firefox, however it also includes one change that could potentially be disruptive to users: It links all of Firefox's internal libraries and extensions statically, into the main binary. This reduces disk space consumption, improves start-time performance and doesn't break any applications that build against Firefox. Mozilla's own binary builds are built this way, in fact.
That makes sense to me.
The reason this could be disruptive is because the final linking to generate the main firefox-bin file requires a lot of RAM, in my experience, 512MB minimum or a large amount of swap to compensate. This could cause build problems for some users, although Danny Rawlins managed to build this port on a system with only 256MB of RAM.
I was able to build opt/firefox on embedded PowerPC with 256MB successfully. But the build doesn't run. I haven't had time to have a closer look what's happening there and I didn't tests on x86 yet. All this needs to be fixed anyway.
I don't have a PowerPC system at my disposal, so I cannot offer any advice there. I'm mostly looking for testing on standard, x86 CRUX, but any testing is welcome.
I wanted to post this here to receive further testing before 2.0.0.13 is released, so that I don't push something potentially destructive to opt.
Push it again or put it in your repo. And please point out where to look closely for any problems.
It is currently in my personal repo, I don't intend to push anything to opt unless I know it works. As I mentioned, the primary thing I am looking for are problems resulting from linking the modified version due to low memory, if prevalent enough I won't merge those respective changes to opt, in order to avoid problems for users.
Regards,
Clemens
-- ~predatorfreak GnuPG Public key: http://pred.dcaf-security.org/dcafsec-pub-gpgkey.asc
On Mon, 3 Mar 2008 08:11:06 -0500 Brett Goulder <predatorfreak@dcaf-security.org> (by way of Brett Goulder <predatorfreak@dcaf-security.org>) wrote:
I was able to build opt/firefox on embedded PowerPC with 256MB successfully. But the build doesn't run. I haven't had time to have a closer look what's happening there and I didn't tests on x86 yet. All this needs to be fixed anyway.
I don't have a PowerPC system at my disposal, so I cannot offer any advice there. I'm mostly looking for testing on standard, x86 CRUX, but any testing is welcome.
compiled succesfully on PowerPC G4 1GHz 512MB CRUX PPC 2.4RC1 and it works fine. # PPC!=upstream: mozconf .footprint greetz, -- acrux <acrux_it@libero.it>
On Mon, 3 Mar 2008 21:16:41 +0100 acrux <acrux_it@libero.it> wrote:
On Mon, 3 Mar 2008 08:11:06 -0500 Brett Goulder <predatorfreak@dcaf-security.org> (by way of Brett Goulder <predatorfreak@dcaf-security.org>) wrote:
I was able to build opt/firefox on embedded PowerPC with 256MB successfully. But the build doesn't run. I haven't had time to have a closer look what's happening there and I didn't tests on x86 yet. All this needs to be fixed anyway.
I don't have a PowerPC system at my disposal, so I cannot offer any advice there. I'm mostly looking for testing on standard, x86 CRUX, but any testing is welcome.
compiled succesfully on PowerPC G4 1GHz 512MB CRUX PPC 2.4RC1 and it works fine.
# PPC!=upstream: mozconf .footprint
mmh... sorry, here the port: http://acrux.homelinux.org:8083/crux-ppc-devel/test/firefox/ -- acrux <acrux_it@libero.it>
On Mon, 3 Mar 2008 04:48:13 -0500 Brett Goulder wrote:
Attached is a Firefox port modified with all the changes I intend to push into the one in opt once 2.0.0.13 is released, mostly it's further debloating for Firefox, however it also includes one change that could potentially be disruptive to users: It links all of Firefox's internal libraries and extensions statically, into the main binary. This reduces disk space consumption, improves start-time performance and doesn't break any applications that build against Firefox. Mozilla's own binary builds are built this way, in fact.
The reason this could be disruptive is because the final linking to generate the main firefox-bin file requires a lot of RAM, in my experience, 512MB minimum or a large amount of swap to compensate. This could cause build problems for some users, although Danny Rawlins managed to build this port on a system with only 256MB of RAM.
I wanted to post this here to receive further testing before 2.0.0.13 is released, so that I don't push something potentially destructive to opt.
An e-mail with the attachment is being delayed due to it's size atm, so in the mean time you can get it from my repo: http://www.dcaf-security.org/ports/firefox or via httpup: httpup sync http://www.dcaf-security.org/ports#firefox firefox -- ~predatorfreak GnuPG Public key: http://pred.dcaf-security.org/dcafsec-pub-gpgkey.asc
Brett Goulder schrieb:
An e-mail with the attachment is being delayed due to it's size atm, so in the mean time you can get it from my repo: http://www.dcaf-security.org/ports/firefox or via httpup: httpup sync http://www.dcaf-security.org/ports#firefox firefox
The ports you present are still on 2.0.0.12-2. I'm building on some machines right now: - Pentium MMX @ 166MHz, 128M RAM, 512M swap - Athlon @ 650MHZ, 196M RAM, 512M swap, - PowerPC MPC8540 @ 833MHZ, 256M RAM, 3G swap Small enough? ... will take lot of time on that sloooow stuff. Clemens
Clemens Koller schrieb:
Brett Goulder schrieb:
An e-mail with the attachment is being delayed due to it's size atm, so in the mean time you can get it from my repo: http://www.dcaf-security.org/ports/firefox or via httpup: httpup sync http://www.dcaf-security.org/ports#firefox firefox
The ports you present are still on 2.0.0.12-2.
I'm building on some machines right now: - Pentium MMX @ 166MHz, 128M RAM, 512M swap
... as I said... it's slow. :-)
- Athlon @ 650MHZ, 196M RAM, 512M swap,
Built fine & works fine.
- PowerPC MPC8540 @ 833MHZ, 256M RAM, 3G swap
Built ok, but doesn't run. It shows the same broken behaviour as my former dynamically linked version. So neither improvement nor regression here. firefox ends up as a zombie with an empty window frame left in X and: 19686 pts/1 S 0:00 /bin/sh /usr/bin/firefox 19698 pts/1 S 0:00 /bin/sh /usr/lib/firefox/run-mozilla.sh /usr/lib/firefox/firefox-bin 19703 pts/1 Zl 0:05 [firefox-bin] <defunct> Any ideas? The dependencies are all solved, but I guess some basic screen-rendering stuff is severely broken here. I will check the mozconfig and try the build with ac_cv_visibility_pragma=no on the PowerPC - tomorrow... (Thanks, acrux for that hint!) Next time I should propably move all the old machines out of my sleeping room... @:-] Regards, Clemens
Clemens Koller wrote:
Clemens Koller schrieb:
Brett Goulder schrieb:
An e-mail with the attachment is being delayed due to it's size atm, so
in the mean time you can get it from my repo: http://www.dcaf-security.org/ports/firefox or via httpup: httpup sync http://www.dcaf-security.org/ports#firefox firefox
The ports you present are still on 2.0.0.12-2.
I'm building on some machines right now: - Pentium MMX @ 166MHz, 128M RAM, 512M swap
... as I said... it's slow. :-)
lol setup distcc, that's what i used on my K6II 450MHz 256MB ram 256MB swap = 512MB to compile with, used distcc but the final linking is what Brett was concerned on, and yes firefox works fine on that computer.
- Athlon @ 650MHZ, 196M RAM, 512M swap,
Built fine & works fine.
- PowerPC MPC8540 @ 833MHZ, 256M RAM, 3G swap
Built ok, but doesn't run. It shows the same broken behaviour as my former dynamically linked version. So neither improvement nor regression here.
firefox ends up as a zombie with an empty window frame left in X and: 19686 pts/1 S 0:00 /bin/sh /usr/bin/firefox 19698 pts/1 S 0:00 /bin/sh /usr/lib/firefox/run-mozilla.sh /usr/lib/firefox/firefox-bin 19703 pts/1 Zl 0:05 [firefox-bin] <defunct>
Any ideas? The dependencies are all solved, but I guess some basic screen-rendering stuff is severely broken here. I will check the mozconfig and try the build with ac_cv_visibility_pragma=no on the PowerPC - tomorrow... (Thanks, acrux for that hint!)
Next time I should propably move all the old machines out of my sleeping room... @:-]
rofl, that's giggle worthy unless ya happen to be the person trying to sleep. [^_^]
Regards,
Clemens _______________________________________________ CRUX mailing list CRUX@lists.crux.nu http://lists.crux.nu/mailman/listinfo/crux
Couldn't build the new port: c++ -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -pedantic -O2 -march=i686 -fomit-frame-pointer -pipe -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -O2 -march=i686 -fomit-frame-pointer -pipe -fvisibility-inlines-hidden -fvisibility=hidden -fPIC -shared -Wl,-z,defs -Wl,-h,libxpcom_core.so -o libxpcom_core.so pldhash.o nsCOMPtr.o nsComponentManagerUtils.o nsDebug.o nsID.o nsIInterfaceRequestorUtils.o nsINIParser.o nsMemory.o nsTraceRefcnt.o nsWeakReference.o nsGREGlue.o nsVersionComparator.o nsTHashtable.o nsTArray.o nsGenericFactory.o nsXPComInit.o nsStringAPI.o -Wl,--whole-archive ../../dist/lib/libxpcomds_s.a ../../dist/lib/libxpcomio_s.a ../../dist/lib/libxpcomcomponents_s.a ../../dist/lib/libxpcomthreads_s.a ../../dist/lib/libxpcomproxy_s.a ../../dist/lib/libxpcombase_s.a ../../dist/lib/libxptcall.a ../../dist/lib/libxptinfo.a ../../dist/lib/libxpt.a ../../dist/lib/libxptcmd.a ../../dist/lib/libstring_s.a -Wl,--no-whole-archive -L/usr/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -ldl -lm /usr/bin/ld: ../../dist/lib/libxptinfo.a(xptiMisc.o)(.text+0x141): unresolvable R_386_GOTOFF relocation against symbol `PR_LocalTimeParameters' /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status make[3]: *** [libxpcom_core.so] Error 1 make[3]: Leaving directory `/usr/ports/work/firefox/src/mozilla/xpcom/build' make[2]: *** [libs] Error 2 make[2]: Leaving directory `/usr/ports/work/firefox/src/mozilla/xpcom' make[1]: *** [tier_2] Error 2 make[1]: Leaving directory `/usr/ports/work/firefox/src/mozilla' make: *** [default] Error 2 =======> ERROR: Building '/usr/ports/pkgs/firefox#2.0.0.12-2.pkg.tar.gz' failed. Google suggests: http://linuxfromscratch.org/pipermail/blfs-support/2006-November/061480.html
Alan wrote:
Couldn't build the new port:
c++ -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -pedantic -O2 -march=i686 -fomit-frame-pointer -pipe -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -O2 -march=i686 -fomit-frame-pointer -pipe -fvisibility-inlines-hidden -fvisibility=hidden -fPIC -shared -Wl,-z,defs -Wl,-h,libxpcom_core.so -o libxpcom_core.so pldhash.o nsCOMPtr.o nsComponentManagerUtils.o nsDebug.o nsID.o nsIInterfaceRequestorUtils.o nsINIParser.o nsMemory.o nsTraceRefcnt.o nsWeakReference.o nsGREGlue.o nsVersionComparator.o nsTHashtable.o nsTArray.o nsGenericFactory.o nsXPComInit.o nsStringAPI.o -Wl,--whole-archive ../../dist/lib/libxpcomds_s.a ../../dist/lib/libxpcomio_s.a ../../dist/lib/libxpcomcomponents_s.a ../../dist/lib/libxpcomthreads_s.a ../../dist/lib/libxpcomproxy_s.a ../../dist/lib/libxpcombase_s.a ../../dist/lib/libxptcall.a ../../dist/lib/libxptinfo.a ../../dist/lib/libxpt.a ../../dist/lib/libxptcmd.a ../../dist/lib/libstring_s.a -Wl,--no-whole-archive -L/usr/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -ldl -lm /usr/bin/ld: ../../dist/lib/libxptinfo.a(xptiMisc.o)(.text+0x141): unresolvable R_386_GOTOFF relocation against symbol `PR_LocalTimeParameters' /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status make[3]: *** [libxpcom_core.so] Error 1 make[3]: Leaving directory `/usr/ports/work/firefox/src/mozilla/xpcom/build' make[2]: *** [libs] Error 2 make[2]: Leaving directory `/usr/ports/work/firefox/src/mozilla/xpcom' make[1]: *** [tier_2] Error 2 make[1]: Leaving directory `/usr/ports/work/firefox/src/mozilla' make: *** [default] Error 2 =======> ERROR: Building '/usr/ports/pkgs/firefox#2.0.0.12-2.pkg.tar.gz' failed.
Google suggests:
http://linuxfromscratch.org/pipermail/blfs-support/2006-November/061480.html
Hmm I'd say try "-fvisibility=hidden" in CXXFLAGS http://gcc.gnu.org/wiki/Visibility
_______________________________________________ CRUX mailing list CRUX@lists.crux.nu http://lists.crux.nu/mailman/listinfo/crux
On Tue, 04 Mar 2008 20:10:12 +1100 Danny Rawlins wrote:
Alan wrote:
Couldn't build the new port:
c++ -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -pedantic -O2 -march=i686 -fomit-frame-pointer -pipe -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -O2 -march=i686 -fomit-frame-pointer -pipe -fvisibility-inlines-hidden -fvisibility=hidden -fPIC -shared -Wl,-z,defs -Wl,-h,libxpcom_core.so -o libxpcom_core.so pldhash.o nsCOMPtr.o nsComponentManagerUtils.o nsDebug.o nsID.o nsIInterfaceRequestorUtils.o nsINIParser.o nsMemory.o nsTraceRefcnt.o nsWeakReference.o nsGREGlue.o nsVersionComparator.o nsTHashtable.o nsTArray.o nsGenericFactory.o nsXPComInit.o nsStringAPI.o -Wl,--whole-archive ../../dist/lib/libxpcomds_s.a ../../dist/lib/libxpcomio_s.a ../../dist/lib/libxpcomcomponents_s.a ../../dist/lib/libxpcomthreads_s.a ../../dist/lib/libxpcomproxy_s.a ../../dist/lib/libxpcombase_s.a ../../dist/lib/libxptcall.a ../../dist/lib/libxptinfo.a ../../dist/lib/libxpt.a ../../dist/lib/libxptcmd.a ../../dist/lib/libstring_s.a -Wl,--no-whole-archive -L/usr/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -ldl -lm /usr/bin/ld: ../../dist/lib/libxptinfo.a(xptiMisc.o)(.text+0x141): unresolvable R_386_GOTOFF relocation against symbol `PR_LocalTimeParameters' /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status make[3]: *** [libxpcom_core.so] Error 1 make[3]: Leaving directory `/usr/ports/work/firefox/src/mozilla/xpcom/build' make[2]: *** [libs] Error 2 make[2]: Leaving directory `/usr/ports/work/firefox/src/mozilla/xpcom' make[1]: *** [tier_2] Error 2 make[1]: Leaving directory `/usr/ports/work/firefox/src/mozilla' make: *** [default] Error 2 =======> ERROR: Building '/usr/ports/pkgs/firefox#2.0.0.12-2.pkg.tar.gz' failed.
Google suggests:
http://linuxfromscratch.org/pipermail/blfs-support/2006-November/061480.html
Hmm I'd say try "-fvisibility=hidden" in CXXFLAGS
I'd say I forgot to remove the -fvisibility=hidden bit that I forced in my personal port, which caused this. Removed that just now, so anyone experiencing this problem should grab the port again and retest.
http://gcc.gnu.org/wiki/Visibility
_______________________________________________ CRUX mailing list CRUX@lists.crux.nu http://lists.crux.nu/mailman/listinfo/crux
_______________________________________________ CRUX mailing list CRUX@lists.crux.nu http://lists.crux.nu/mailman/listinfo/crux
-- ~predatorfreak GnuPG Public key: http://pred.dcaf-security.org/dcafsec-pub-gpgkey.asc
El Mar 04 Mar 2008, Brett Goulder escribió:
On Tue, 04 Mar 2008 20:10:12 +1100
Danny Rawlins wrote:
Alan wrote:
Couldn't build the new port:
c++ -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -pedantic -O2 -march=i686 -fomit-frame-pointer -pipe -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -O2 -march=i686 -fomit-frame-pointer -pipe -fvisibility-inlines-hidden -fvisibility=hidden -fPIC -shared -Wl,-z,defs -Wl,-h,libxpcom_core.so -o libxpcom_core.so pldhash.o nsCOMPtr.o nsComponentManagerUtils.o nsDebug.o nsID.o nsIInterfaceRequestorUtils.o nsINIParser.o nsMemory.o nsTraceRefcnt.o nsWeakReference.o nsGREGlue.o nsVersionComparator.o nsTHashtable.o nsTArray.o nsGenericFactory.o nsXPComInit.o nsStringAPI.o -Wl,--whole-archive ../../dist/lib/libxpcomds_s.a ../../dist/lib/libxpcomio_s.a ../../dist/lib/libxpcomcomponents_s.a ../../dist/lib/libxpcomthreads_s.a ../../dist/lib/libxpcomproxy_s.a ../../dist/lib/libxpcombase_s.a ../../dist/lib/libxptcall.a ../../dist/lib/libxptinfo.a ../../dist/lib/libxpt.a ../../dist/lib/libxptcmd.a ../../dist/lib/libstring_s.a -Wl,--no-whole-archive -L/usr/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -ldl -lm /usr/bin/ld: ../../dist/lib/libxptinfo.a(xptiMisc.o)(.text+0x141): unresolvable R_386_GOTOFF relocation against symbol `PR_LocalTimeParameters' /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status make[3]: *** [libxpcom_core.so] Error 1 make[3]: Leaving directory `/usr/ports/work/firefox/src/mozilla/xpcom/build' make[2]: *** [libs] Error 2 make[2]: Leaving directory `/usr/ports/work/firefox/src/mozilla/xpcom' make[1]: *** [tier_2] Error 2 make[1]: Leaving directory `/usr/ports/work/firefox/src/mozilla' make: *** [default] Error 2 =======> ERROR: Building '/usr/ports/pkgs/firefox#2.0.0.12-2.pkg.tar.gz' failed.
Google suggests:
http://linuxfromscratch.org/pipermail/blfs-support/2006-November/061480 .html
Hmm I'd say try "-fvisibility=hidden" in CXXFLAGS
I'd say I forgot to remove the -fvisibility=hidden bit that I forced in my personal port, which caused this. Removed that just now, so anyone experiencing this problem should grab the port again and retest.
I had to remove the complete CFLAGS line and add "ac_cv_visibility_pragma=no" to my mozconfig to be able to build it. I'm using GCC 4.2.2. I wonder why I had to do this and you didn't. Comparing this port with the previous one: firefox#2.0.0.11-1.pkg.tar.gz: 14002213 bytes 4704 files firefox#2.0.0.12-2.pkg.tar.gz: 11621062 bytes 3413 files I haven't noticed any other difference yet, except that startup time seems faster, but this might be subjective. Thanks for your work. -- Alan
On Tue, 4 Mar 2008 09:33:43 -0430 Alan wrote:
El Mar 04 Mar 2008, Brett Goulder escribió:
On Tue, 04 Mar 2008 20:10:12 +1100
Danny Rawlins wrote:
Alan wrote:
Couldn't build the new port:
c++ -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -pedantic -O2 -march=i686 -fomit-frame-pointer -pipe -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -O2 -march=i686 -fomit-frame-pointer -pipe -fvisibility-inlines-hidden -fvisibility=hidden -fPIC -shared -Wl,-z,defs -Wl,-h,libxpcom_core.so -o libxpcom_core.so pldhash.o nsCOMPtr.o nsComponentManagerUtils.o nsDebug.o nsID.o nsIInterfaceRequestorUtils.o nsINIParser.o nsMemory.o nsTraceRefcnt.o nsWeakReference.o nsGREGlue.o nsVersionComparator.o nsTHashtable.o nsTArray.o nsGenericFactory.o nsXPComInit.o nsStringAPI.o -Wl,--whole-archive ../../dist/lib/libxpcomds_s.a ../../dist/lib/libxpcomio_s.a ../../dist/lib/libxpcomcomponents_s.a ../../dist/lib/libxpcomthreads_s.a ../../dist/lib/libxpcomproxy_s.a ../../dist/lib/libxpcombase_s.a ../../dist/lib/libxptcall.a ../../dist/lib/libxptinfo.a ../../dist/lib/libxpt.a ../../dist/lib/libxptcmd.a ../../dist/lib/libstring_s.a -Wl,--no-whole-archive -L/usr/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -ldl -lm /usr/bin/ld: ../../dist/lib/libxptinfo.a(xptiMisc.o)(.text+0x141): unresolvable R_386_GOTOFF relocation against symbol `PR_LocalTimeParameters' /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status make[3]: *** [libxpcom_core.so] Error 1 make[3]: Leaving directory `/usr/ports/work/firefox/src/mozilla/xpcom/build' make[2]: *** [libs] Error 2 make[2]: Leaving directory `/usr/ports/work/firefox/src/mozilla/xpcom' make[1]: *** [tier_2] Error 2 make[1]: Leaving directory `/usr/ports/work/firefox/src/mozilla' make: *** [default] Error 2 =======> ERROR: Building '/usr/ports/pkgs/firefox#2.0.0.12-2.pkg.tar.gz' failed.
Google suggests:
http://linuxfromscratch.org/pipermail/blfs-support/2006-November/061480 .html
Hmm I'd say try "-fvisibility=hidden" in CXXFLAGS
I'd say I forgot to remove the -fvisibility=hidden bit that I forced in my personal port, which caused this. Removed that just now, so anyone experiencing this problem should grab the port again and retest.
I had to remove the complete CFLAGS line and add "ac_cv_visibility_pragma=no" to my mozconfig to be able to build it.
I'm using GCC 4.2.2. I wonder why I had to do this and you didn't.
Comparing this port with the previous one:
firefox#2.0.0.11-1.pkg.tar.gz: 14002213 bytes 4704 files firefox#2.0.0.12-2.pkg.tar.gz: 11621062 bytes 3413 files
I haven't noticed any other difference yet, except that startup time seems faster, but this might be subjective.
Thanks for your work.
As far as I can tell, it is in fact a real-world gain. However, as I said, the primary benefits are disk space and reduced start up time. I will probably add the ac_cv_visibility_pragma=no bit, in addition to the fact that I removed the CFLAGS line, in order to avoid further problems with visibility. (Are you sure just removing the CFLAGS didn't fix it?) -- ~predatorfreak GnuPG Public key: http://pred.dcaf-security.org/dcafsec-pub-gpgkey.asc
El Mar 04 Mar 2008, Brett Goulder escribió:
I will probably add the ac_cv_visibility_pragma=no bit, in addition to the fact that I removed the CFLAGS line, in order to avoid further problems with visibility. (Are you sure just removing the CFLAGS didn't fix it?)
Yes, I'm sure. Am I the only one trying to build this port with gcc 4.2.2? Can anybody else with this version give it a try? -- Alan
Hello, On Tue, 4 Mar 2008 14:32:41 -0430 Alan <alan+crux@mizrahi.com.ve> wrote:
El Mar 04 Mar 2008, Brett Goulder escribió:
I will probably add the ac_cv_visibility_pragma=no bit, in addition to the fact that I removed the CFLAGS line, in order to avoid further problems with visibility. (Are you sure just removing the CFLAGS didn't fix it?)
Yes, I'm sure. Am I the only one trying to build this port with gcc 4.2.2? Can anybody else with this version give it a try?
I can build and run the port in version 2.0.0.12-3 with gcc 4.2.2 without problems. BTW: My computer has got 512 MB RAM and 256 MB swap. Regards, Markus
Alan schrieb:
El Mar 04 Mar 2008, Brett Goulder escribió:
I will probably add the ac_cv_visibility_pragma=no bit, in addition to the fact that I removed the CFLAGS line, in order to avoid further problems with visibility. (Are you sure just removing the CFLAGS didn't fix it?)
Yes, I'm sure. Am I the only one trying to build this port with gcc 4.2.2? Can anybody else with this version give it a try?
... did all my x86 stuff with gcc-4.2.2 (my PowerPC has gcc-4.2.3 on it). Regards, Clemens
On Tue, 4 Mar 2008 14:32:41 -0430 Alan wrote:
El Mar 04 Mar 2008, Brett Goulder escribió:
I will probably add the ac_cv_visibility_pragma=no bit, in addition to the fact that I removed the CFLAGS line, in order to avoid further problems with visibility. (Are you sure just removing the CFLAGS didn't fix it?)
Yes, I'm sure. Am I the only one trying to build this port with gcc 4.2.2? Can anybody else with this version give it a try?
The version of GCC in core is 4.2.2, that's what I'm using. It builds fine with visibility here. -- ~predatorfreak GnuPG Public key: http://pred.dcaf-security.org/dcafsec-pub-gpgkey.asc
On Tue, 4 Mar 2008 14:32:41 -0430 Alan wrote:
El Mar 04 Mar 2008, Brett Goulder escribió:
I will probably add the ac_cv_visibility_pragma=no bit, in addition to the fact that I removed the CFLAGS line, in order to avoid further problems with visibility. (Are you sure just removing the CFLAGS didn't fix it?)
Yes, I'm sure. Am I the only one trying to build this port with gcc 4.2.2? Can anybody else with this version give it a try?
I'm wondering as PR_LocalTimeParameters is actually an nss symbol, is your nss up-to-date and does it match the one in opt? -- ~predatorfreak GnuPG Public key: http://pred.dcaf-security.org/dcafsec-pub-gpgkey.asc
El Mié 05 Mar 2008, Brett Goulder escribió:
On Tue, 4 Mar 2008 14:32:41 -0430
Alan wrote:
El Mar 04 Mar 2008, Brett Goulder escribió:
I will probably add the ac_cv_visibility_pragma=no bit, in addition to the fact that I removed the CFLAGS line, in order to avoid further problems with visibility. (Are you sure just removing the CFLAGS didn't fix it?)
Yes, I'm sure. Am I the only one trying to build this port with gcc 4.2.2? Can anybody else with this version give it a try?
I'm wondering as PR_LocalTimeParameters is actually an nss symbol, is your nss up-to-date and does it match the one in opt?
Yes, my nss installation wasn't updated. I updated nss and rebuilt firefox without forcing CFLAGS and without "ac_cv_visibility_pragma=no", it worked. Regards, -- Alan
On Mon, 03 Mar 2008 04:48:13 -0500 Brett Goulder wrote:
Attached is a Firefox port modified with all the changes I intend to push into the one in opt once 2.0.0.13 is released, mostly it's further debloating for Firefox, Swiftweasel [http://swiftweasel.tuxfamily.org/] already does that, iirc, so why not just package that?
This reduces disk space consumption, improves start-time performance and doesn't break any applications that build against Firefox. Mozilla's own binary builds are built this way, in fact. With large disks these days, disk space is not that much of an issue.If several Mb saved this way are important to you, then, by all means, do it, but it's not worth the effort, unless in special/different circumstances, which do not apply here (again IMWHO :) ).
Start-time performance?Firefox startup is one-time event(start it up,use it, keep it open for a few days until it either chews large chunk of RAM or extensions need updating, then close/restart it). Anyway, if Mozilla's own binary builds are made that way, why just don't package and use them?Or Swiftweasel, for that matter? Or Debian's Iceweasel, debranded version? Crux philosophy is KISS, right?So why not do this in a simple, most elegant manner possible i.e in a way it was done so far? If you really want 'debloated' version of FF, use one of the alternatives above, and/or push alternative port to opt/contrib. Pedja -- If it looks like a troll, smells like a troll and quacks like a troll... ... kill it. It's a troll. - Mike Whitaker talking sense, in ukmg.
On Wed, 5 Mar 2008 05:41:50 +0100 Predrag Ivanovic wrote:
On Mon, 03 Mar 2008 04:48:13 -0500 Brett Goulder wrote:
Attached is a Firefox port modified with all the changes I intend to push into the one in opt once 2.0.0.13 is released, mostly it's further debloating for Firefox, Swiftweasel [http://swiftweasel.tuxfamily.org/] already does that, iirc, so why not just package that?
We are packaging upstream Firefox, as built for CRUX. In addition, Swiftweasal, Swiftfox, etc do not debloat Firefox, they build it with riced-out CFLAGS in the hopes of gaining tiny improvements in performance, that's not the point of this, the point is improving our build of Firefox.
This reduces disk space consumption, improves start-time performance and doesn't break any applications that build against Firefox. Mozilla's own binary builds are built this way, in fact. With large disks these days, disk space is not that much of an issue.If several Mb saved this way are important to you, then, by all means, do it, but it's not worth the effort, unless in special/different circumstances, which do not apply here (again IMWHO :) ).
It is not an extensive amount of work, saving a few megabytes here and there is a worthwhile cause, considering that Firefox uncompressed is about a ~48-52MB install for just a browser, saving disk space is worthwhile, why waste disk space for no apparent reason?
Start-time performance?Firefox startup is one-time event(start it up,use it, keep it open for a few days until it either chews large chunk of RAM or extensions need updating, then close/restart it).
Not everyone uses Firefox this way, just because you do does not mean everyone does. Again, debloating in addition to reducing the speed at which it starts are both worthwhile improvements when it causes the users no grievances (hence the point of testing this).
Anyway, if Mozilla's own binary builds are made that way, why just don't package and use them?Or Swiftweasel, for that matter? Or Debian's Iceweasel, debranded version?
As I already said, we're packaging Firefox, not Swiftweasel or Iceweasel or any other modification of Firefox. The reason we use our own builds is two-fold: First, CRUX is a primarily source-based distro, not a binary distro, unless it would be entirely insane to build it from source (I.E. OpenOffice) or impossible due the program being closed-source, then we try to build from source. Second, The official builds provided by Mozilla do not include development headers, we cannot build plugins against a pure binary build.
Crux philosophy is KISS, right?So why not do this in a simple, most elegant manner possible i.e in a way it was done so far? If you really want 'debloated' version of FF, use one of the alternatives above, and/or push alternative port to opt/contrib. Pedja
KISS doesn't mean we utilise some other build of Firefox merely because they've already packaged it, if we were to start doing that, we would have to start packaging everyone elses packages for coreutils and libpng and this-and-that. KISS is a design philosophy, not a packaging philosophy. Iceweasal, Swiftweasal, etc are not "debloated" versions, I think you're confusing reducing the disk footprint of a Firefox installation with tweaking performance, I am not attempting to gain significant improvements in performance by removing files which waste diskspace and improving how Firefox is built, I am attempting to reduce the wasted disk space that is so prevalent in Firefox. -- ~predatorfreak GnuPG Public key: http://pred.dcaf-security.org/dcafsec-pub-gpgkey.asc
On Wed, 05 Mar 2008 06:10:54 -0500 Brett Goulder wrote: <snip>
Start-time performance?Firefox startup is one-time event(start it up,use it, keep it open for a few days until it either chews large chunk of RAM or extensions need updating, then close/restart it).
Not everyone uses Firefox this way, just because you do does not mean everyone does. I thought it's obvious that I'm talking about the way *I* use FF.How others use it I don't really care, to be honest.
Again, debloating in addition to reducing the speed at which it starts are both worthwhile improvements when it causes the users no grievances (hence the point of testing this).
And it is perfectly valid point, and I respect your desire to improve/debloat/whatever Firefox port. What I tried to say(and failed miserably, it seems :) ), is that with the way *I* use Firefox, things that you want to improve are a non-issue for me i.e I don't care about them, but if there are people that do care(and you are one of them, obviously), and you improve Firefox port, I have absolutely no problem with that. Pedja -- Seen on eBay: "Praise : Complete Fraud! Took all our money and never received any product"
El Mié 05 Mar 2008, Predrag Ivanovic escribió:
And it is perfectly valid point, and I respect your desire to improve/debloat/whatever Firefox port. What I tried to say(and failed miserably, it seems :) ), is that with the way *I* use Firefox, things that you want to improve are a non-issue for me i.e I don't care about them, but if there are people that do care(and you are one of them, obviously), and you improve Firefox port, I have absolutely no problem with that.
I think that Brett is doing an great job that benefits all of us, even you, and even if you don't care about disk space or startup times. I do care if the next version of the firefox port has less files than the previous one. In fact I think everyone should care, because smaller ports with less files not only saves disk space, it also translates to smaller backups that are faster to complete. Its not like its going to hurt you ;) I am looking forward to a less bloated port of OpenOffice too, even if it requires two days of compilation time. Regards, Alan -- Alan Mizrahi +58-412-2228889
participants (7)
-
acrux -
Alan -
Brett Goulder -
Clemens Koller -
Danny Rawlins -
Markus Heinz -
Predrag Ivanovic