Re: [blfs-dev] #3982: Firefox-23.0.1/Xulrunner-23.0.1
Em 18-08-2013 22:13, Fernando de Oliveira escreveu: Em 18-08-2013 17:46, Bruce Dubbs escreveu: Fernando de Oliveira wrote: Em 18-08-2013 13:59, Ken Moffat escreveu: On Sun, Aug 18, 2013 at 09:06:36AM -0500, Bruce Dubbs wrote: BLFS Trac wrote: #3982: Firefox-23.0.1/Xulrunner-23.0.1 * resolution: = fixed Comment: Fixed at revision 11650. Xulrunner, the first I built, needed over 3.3GB of memory, and ld died. Had to increase memory. Memory or disk space? I wouldn't think anything needs 3.3G RAM to compile. -- Bruce From my experience with 23.0, memory. At the end of the build it seems to link everything together and goes into swap on my boxes with only 4GB of RAM (running icewm, a handful of urxvt terms). ĸen Thanks, ĸen, for confirming. This was a long standing issue, never remeber to ask/inform. And it seems that my interpretation was not so wrong. Command attached before was broken incomplete. I hope you all do not mind, but I am sending another one, from a build log, deleted previous and following lines, leaving some which seemed relevant. This all seems like it's consistent. Perhaps a note about the RAM/swap would be appropriate. OK. I will do it. I have a problem with this: [attached pdf, comparing six systems] I have omitted the system having 16GB of RAM. Have rebuilt yesterday, to confirm numbers, with the developing system with increased memory. It seems total memory size was about the value used when linking libxul, when I read while building yesterday, so it failed for a small amount, 200MB was already used, before build started. But why the i686 systems do not fail? Without much experience with x86_64, builds, may I assume that binaries are larger for this architecture? Is it reasonable to insert a note for xulrunner's page mentioning it is only with x86_64 architecture that the problem occurs? -- []s, Fernando xulrunner-23.0.1-VM-memory-comparison-only-table.pdf Description: Adobe PDF document -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] #3982: Firefox-23.0.1/Xulrunner-23.0.1
Fernando de Oliveira wrote: Em 18-08-2013 22:13, Fernando de Oliveira escreveu: Em 18-08-2013 17:46, Bruce Dubbs escreveu: Command attached before was broken incomplete. I hope you all do not mind, but I am sending another one, from a build log, deleted previous and following lines, leaving some which seemed relevant. This all seems like it's consistent. Perhaps a note about the RAM/swap would be appropriate. OK. I will do it. I have a problem with this: [attached pdf, comparing six systems] I have omitted the system having 16GB of RAM. Yes, the system will need more RAM/Swap when using a high -j value. Have rebuilt yesterday, to confirm numbers, with the developing system with increased memory. It seems total memory size was about the value used when linking libxul, when I read while building yesterday, so it failed for a small amount, 200MB was already used, before build started. But why the i686 systems do not fail? Without much experience with x86_64, builds, may I assume that binaries are larger for this architecture? My benchmarks some time ago showed that 64-bit binaries were about 15% larger than 32-bit binaries. I would think that would hold in memory too. Is it reasonable to insert a note for xulrunner's page mentioning it is only with x86_64 architecture that the problem occurs? I'm not sure about that. My first thought is that the different compilers may need significantly different amounts of memory. I'd just note that On some systems, the RAM/Swap combination needs 6 GB of memory available. or something similar to that. It's hard to pin it down more than that. Extra swap today doesn't really cost the user a lot. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] #3982: Firefox-23.0.1/Xulrunner-23.0.1
Em 19-08-2013 11:42, Bruce Dubbs escreveu: Fernando de Oliveira wrote: ... Is it reasonable to insert a note for xulrunner's page mentioning it is only with x86_64 architecture that the problem occurs? I'm not sure about that. My first thought is that the different compilers may need significantly different amounts of memory. I'd just note that On some systems, the RAM/Swap combination needs 6 GB of memory available. or something similar to that. It's hard to pin it down more than that. Extra swap today doesn't really cost the user a lot. Done with revision 11656. Thanks for clarifying some points, for the suggestions, everything. -- []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] #3982: Firefox-23.0.1/Xulrunner-23.0.1
BLFS Trac wrote: #3982: Firefox-23.0.1/Xulrunner-23.0.1 * resolution: = fixed Comment: Fixed at revision 11650. Xulrunner, the first I built, needed over 3.3GB of memory, and ld died. Had to increase memory. Memory or disk space? I wouldn't think anything needs 3.3G RAM to compile. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] #3982: Firefox-23.0.1/Xulrunner-23.0.1
Em 18-08-2013 11:06, Bruce Dubbs escreveu: BLFS Trac wrote: #3982: Firefox-23.0.1/Xulrunner-23.0.1 * resolution: = fixed Comment: Fixed at revision 11650. Xulrunner, the first I built, needed over 3.3GB of memory, and ld died. Had to increase memory. Memory or disk space? I wouldn't think anything needs 3.3G RAM to compile. -- Bruce Perhaps disk space, but not partition space, I believe. If it was not this problem, I would have commited much earlier, still on the 17th, same day of release. First, build died repeatedly at the same point (attached, all five VMs are at this stuck point, now, it was lucky, hope I copied/pasted it correctly). Then, I follow disk/memory usage, and very rapidly, RAM and swap were 100% full, and the command taking more meory, called probably by that python script - or is it called python program? I cannot open the machine where it occurred to see, other three VMs are building xulrunner, now. A message of ld dead, Error 9, sent me in the internet to errors related to not enough swap. It was a VM, so, it was easier to increase the RAM than increase the 1.5GB swap. I increased RAM to 4GB, followed with htop through ssh in a tablet, and at sometime, it was using 3.3GB of RAM, swap not used anymore. Left it there, and later, it had finally completed. With these observations, I called memory, instead of talking about RAM or swap. Other reason to increase the RAM, not swap, is that, obviously, a process taking place in RAM should be faster than in disk. It could be something wrong with that machine (only lfs x86_64 I have). Sometime ago (perhaps a couple of years), I followed these mozilla applications (SeaMonkey included), because one day, what was a reasonably fast compile/link, suddenly became increasingly very slow, from one version to the next, and discovered that was at this same point of the attached command. I think it is were libxul is linked. Some of the machines started to become unresponsive during that command, so I increased the 1GB RAM to 1.5GB, long ago, and things got better. One thing I am sure, each new version of these programs, more memory and time are needed. In my old days of FORTRAN, when compile and link were clearly separated, I would be sure, but these days, I am still struggling to understand these things. The VMS running now have 1.5GB of RAM, in this host, and two others, in another host, only have 1.0GB, running now, too. Since these problems started, I keep the VMs at the login, no X, and use ssh, to increase available RAM. -- []s, Fernando libxul.so rm -f libxul.so /media/dados/home/fernando/tmp/paco-build-2013.08.18-10h58m52s/xulrunner-build-dir/_virtualenv/bin/python /media/dados/home/fernando/tmp/paco-build-2013.08.18-10h58m52s/mozilla-release/config/expandlibs_exec.py --depend .deps/libxul.so.pp --target libxul.so --uselist -- c++ -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body -Wsign-compare -Wno-invalid-offsetof -Wcast-align -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -std=gnu++0x -fno-tree-vrp -pthread -pipe -DNDEBUG -DTRIMMED -g -Os -freorder-blocks -fomit-frame-pointer -fPIC -shared -Wl,-z,defs -Wl,-h,libxul.so -o libxul.so nsStaticXULComponents.o nsUnicharUtils.o nsBidiUtils.o nsSpecialCasingData.o nsUnicodeProperties.o nsRDFResource.o-lpthread -Wl,-z,noexecstack -Wl,--build-id -Wl,-rpath-link,/media/dados/home/fernando/tmp/paco-build-2013.08.18-10h58m52s/xulrunner-build-dir/dist/bin -Wl,-rpath-link,/usr/lib ../../media/kiss_fft/libkiss_fft.a ../../toolkit/components/osfile/libosfile_s.a ../../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/libidentity.a ../../staticlib/components/libimglib2.a ../../staticlib/components/libmediasniffer.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/libtelemetry.a ../../staticlib/components/libjsinspector.a ../../staticlib/components/libjsdebugger.a ../../staticlib/components/libstoragecomps.a ../../staticlib/components/librdf.a ../../staticlib/components/libwindowds.a
Re: [blfs-dev] #3982: Firefox-23.0.1/Xulrunner-23.0.1
Em 18-08-2013 11:06, Bruce Dubbs escreveu: BLFS Trac wrote: #3982: Firefox-23.0.1/Xulrunner-23.0.1 * resolution: = fixed Comment: Fixed at revision 11650. Xulrunner, the first I built, needed over 3.3GB of memory, and ld died. Had to increase memory. Memory or disk space? I wouldn't think anything needs 3.3G RAM to compile. -- Bruce This is reply N.2. All 5 VMs finished. They run with 4 CPU's, are i686. Two, as I said before, 1GB RAM, running in other host, 3 have 1.5GB, running on this host that have many other things, including FF and TB, running as well. In the other host, times were SBU_TIME: 36.00411522 SBU_TIME: 35.76518218 In this host, SBU_TIME: 49.10614525 SBU_TIME: 52.3750 SBU_TIME: 59.61038961 Perhaps, again, the fact that I have an AMD_64 running on a i686 host running inside a 32bit vmplayer explains why this machine always gave me trouble. It was built to replace this host. Would copy and change whatever needed, for physical, instead of virtual hardware, as done before, is more practical than what I did with LFS7.2, built directly on a physical machine. But as I have written before, discovered that, for many reasons, still need 32bit. Then, waited for LFS7.4, to build a new complete one, 32bit. I only need 64bit for creating OJDK binary for the book. Hope to start building tomorrow. -- []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] #3982: Firefox-23.0.1/Xulrunner-23.0.1
Fernando de Oliveira wrote: Em 18-08-2013 11:06, Bruce Dubbs escreveu: BLFS Trac wrote: #3982: Firefox-23.0.1/Xulrunner-23.0.1 * resolution: = fixed Comment: Fixed at revision 11650. Xulrunner, the first I built, needed over 3.3GB of memory, and ld died. Had to increase memory. Memory or disk space? I wouldn't think anything needs 3.3G RAM to compile. -- Bruce Perhaps disk space, but not partition space, I believe. If it was not this problem, I would have commited much earlier, still on the 17th, same day of release. First, build died repeatedly at the same point (attached, all five VMs are at this stuck point, now, it was lucky, hope I copied/pasted it correctly). Then, I follow disk/memory usage, and very rapidly, RAM and swap were 100% full, and the command taking more meory, called probably by that python script - or is it called python program? I cannot open the machine where it occurred to see, other three VMs are building xulrunner, now. A message of ld dead, Error 9, sent me in the internet to errors related to not enough swap. It was a VM, so, it was easier to increase the RAM than increase the 1.5GB swap. I increased RAM to 4GB, followed with htop through ssh in a tablet, and at sometime, it was using 3.3GB of RAM, swap not used anymore. Left it there, and later, it had finally completed. With these observations, I called memory, instead of talking about RAM or swap. Other reason to increase the RAM, not swap, is that, obviously, a process taking place in RAM should be faster than in disk. It could be something wrong with that machine (only lfs x86_64 I have). Sometime ago (perhaps a couple of years), I followed these mozilla applications (SeaMonkey included), because one day, what was a reasonably fast compile/link, suddenly became increasingly very slow, from one version to the next, and discovered that was at this same point of the attached command. I think it is were libxul is linked. Some of the machines started to become unresponsive during that command, so I increased the 1GB RAM to 1.5GB, long ago, and things got better. One thing I am sure, each new version of these programs, more memory and time are needed. In my old days of FORTRAN, when compile and link were clearly separated, I would be sure, but these days, I am still struggling to understand these things. The VMS running now have 1.5GB of RAM, in this host, and two others, in another host, only have 1.0GB, running now, too. Since these problems started, I keep the VMs at the login, no X, and use ssh, to increase available RAM. Hmm. I do note that Xulrunner says you need 5G of disk space. I guess I didn't notice the RAM requirement since I have 10G or ram on my development system. There are a few packages in BLFS that are very big: openjdk-buildsize 9.2 GB gcc-buildsize 6.2 GB JS-buildsize 1.2 GB wireshark-buildsize 1.1 GB texlive-buildsize 1.6 GB qt4-buildsize 1.9 GB qt5-buildsize 2.5 GB xulrunner-buildsize 4.9 GB firefox-buildsize 4.9 GB seamonkey-buildsize 1.6 GB AbiWord-buildsize 1.8 GB libreoffice-buildsize 6.1 GB thunderbird-buildsize 3.1 GB inkscape-buildsize2.0 GB I would want at least 2G of RAM for any of these. It's interesting that seamonkey is so much smaller than ff or tb. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] #3982: Firefox-23.0.1/Xulrunner-23.0.1
Em 18-08-2013 13:59, Ken Moffat escreveu: On Sun, Aug 18, 2013 at 09:06:36AM -0500, Bruce Dubbs wrote: BLFS Trac wrote: #3982: Firefox-23.0.1/Xulrunner-23.0.1 * resolution: = fixed Comment: Fixed at revision 11650. Xulrunner, the first I built, needed over 3.3GB of memory, and ld died. Had to increase memory. Memory or disk space? I wouldn't think anything needs 3.3G RAM to compile. -- Bruce From my experience with 23.0, memory. At the end of the build it seems to link everything together and goes into swap on my boxes with only 4GB of RAM (running icewm, a handful of urxvt terms). ĸen Thanks, ĸen, for confirming. This was a long standing issue, never remeber to ask/inform. And it seems that my interpretation was not so wrong. Command attached before was broken incomplete. I hope you all do not mind, but I am sending another one, from a build log, deleted previous and following lines, leaving some which seemed relevant. -- []s, Fernando libxul.so rm -f libxul.so /media/Dados1T/NovoGamer/home/fernando/tmp/paco-build-2013.08.17-16h23m11s/mozilla-release/xulrunner-build-dir/_virtualenv/bin/python /media/Dados1T/NovoGamer/home/fernando/tmp/paco-build-2013.08.17-16h23m11s/mozilla-release/config/expandlibs_exec.py --depend .deps/libxul.so.pp --target libxul.so --uselist -- c++ -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body -Wsign-compare -Wno-invalid-offsetof -Wcast-align -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -std=gnu++0x -pthread -pipe -DNDEBUG -DTRIMMED -g -Os -freorder-blocks -fomit-frame-pointer -fPIC -shared -Wl,-z,defs -Wl,--gc-sections -Wl,-h,libxul.so -o libxul.so nsStaticXULComponents.o nsUnicharUtils.o nsBidiUtils.o nsSpecialCasingData.o nsUnicodeProperties.o nsRDFResource.o-lpthread -Wl,-z,noexecstack -Wl,--build-id -Wl,-rpath-link,/media/Dados1T/NovoGamer/home/fernando/tmp/paco-build-2013.08.17-16h23m11s/mozilla-release/xulrunner-build-dir/dist/bin -Wl,-rpath-link,/usr/lib ../../media/kiss_fft/libkiss_fft.a ../../toolkit/components/osfile/libosfile_s.a ../../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/libidentity.a ../../staticlib/components/libimglib2.a ../../staticlib/components/libmediasniffer.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/libtelemetry.a ../../staticlib/components/libjsinspector.a ../../staticlib/components/libjsdebugger.a ../../staticlib/components/libstoragecomps.a ../../staticlib/components/librdf.a ../../staticlib/components/libwindowds.a ../../staticlib/components/libdiskspacewatcher.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/libimgicon.a ../../staticlib/components/libprofiler.a ../../staticlib/components/libaccessibility.a ../../staticlib/components/libremoteservice.a ../../staticlib/components/libspellchecker.a ../../staticlib/components/libzipwriter.a ../../staticlib/components/libservices-crypto.a ../../staticlib/components/libnkgio.a ../../staticlib/components/libpeerconnection.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/libgfxipc_s.a ../../staticlib/libhal_s.a ../../staticlib/libdombindings_s.a ../../staticlib/libxpcom_core.a ../../staticlib/libucvutil_s.a ../../staticlib/libchromium_s.a ../../staticlib/libsnappy_s.a
Re: [blfs-dev] #3982: Firefox-23.0.1/Xulrunner-23.0.1
Fernando de Oliveira wrote: Em 18-08-2013 13:59, Ken Moffat escreveu: On Sun, Aug 18, 2013 at 09:06:36AM -0500, Bruce Dubbs wrote: BLFS Trac wrote: #3982: Firefox-23.0.1/Xulrunner-23.0.1 * resolution: = fixed Comment: Fixed at revision 11650. Xulrunner, the first I built, needed over 3.3GB of memory, and ld died. Had to increase memory. Memory or disk space? I wouldn't think anything needs 3.3G RAM to compile. -- Bruce From my experience with 23.0, memory. At the end of the build it seems to link everything together and goes into swap on my boxes with only 4GB of RAM (running icewm, a handful of urxvt terms). ĸen Thanks, ĸen, for confirming. This was a long standing issue, never remeber to ask/inform. And it seems that my interpretation was not so wrong. Command attached before was broken incomplete. I hope you all do not mind, but I am sending another one, from a build log, deleted previous and following lines, leaving some which seemed relevant. This all seems like it's consistent. Perhaps a note about the RAM/swap would be appropriate. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] #3982: Firefox-23.0.1/Xulrunner-23.0.1
Em 18-08-2013 17:46, Bruce Dubbs escreveu: Fernando de Oliveira wrote: Em 18-08-2013 13:59, Ken Moffat escreveu: On Sun, Aug 18, 2013 at 09:06:36AM -0500, Bruce Dubbs wrote: BLFS Trac wrote: #3982: Firefox-23.0.1/Xulrunner-23.0.1 * resolution: = fixed Comment: Fixed at revision 11650. Xulrunner, the first I built, needed over 3.3GB of memory, and ld died. Had to increase memory. Memory or disk space? I wouldn't think anything needs 3.3G RAM to compile. -- Bruce From my experience with 23.0, memory. At the end of the build it seems to link everything together and goes into swap on my boxes with only 4GB of RAM (running icewm, a handful of urxvt terms). ĸen Thanks, ĸen, for confirming. This was a long standing issue, never remeber to ask/inform. And it seems that my interpretation was not so wrong. Command attached before was broken incomplete. I hope you all do not mind, but I am sending another one, from a build log, deleted previous and following lines, leaving some which seemed relevant. This all seems like it's consistent. Perhaps a note about the RAM/swap would be appropriate. OK. I will do it. -- []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
