Darrell,
koffice was building perfectly -- until it hit:
/bin/sh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../.. -I. -I../../../lib/kofficeui -I../../../lib/kofficeui -I../../../lib/kofficecore -I../../../lib/kofficecore -I../../../lib/store -I../../../lib/store -I../../../lib/kwmf -I../../../lib/kwmf -I../../../lib/kopalette -I../../../lib/kopalette -I../../../chalk -I../../../chalk/core -I../../../chalk/sdk -I../../../chalk/core/tiles -I../../../chalk/chalkcolor -I../../../chalk/ui -I../../../lib/kofficeui -I../../../lib/kofficeui -I../../../lib/kofficecore -I../../../lib/kofficecore -I../../../lib/store -I../../../lib/store -I../../../lib/kwmf -I../../../lib/kwmf -I../../../lib/kopalette -I../../../lib/kopalette -I../../../lib/interfaces -I../../../lib/kopainter -I../../../lib/kopainter -I/opt/trinity/include -I/opt/tqt3/include -I. -include tqt.h -DQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -fno-builtin -g3 -fno-inline -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -I/usr/include/tqt -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DHAVE_KNEWSTUFF -fexceptions -MT kis_png_converter.lo -MD -MP -MF .deps/kis_png_converter.Tpo -c -o kis_png_converter.lo kis_png_converter.cc libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../.. -I. -I../../../lib/kofficeui -I../../../lib/kofficeui -I../../../lib/kofficecore -I../../../lib/kofficecore -I../../../lib/store -I../../../lib/store -I../../../lib/kwmf -I../../../lib/kwmf -I../../../lib/kopalette -I../../../lib/kopalette -I../../../chalk -I../../../chalk/core -I../../../chalk/sdk -I../../../chalk/core/tiles -I../../../chalk/chalkcolor -I../../../chalk/ui -I../../../lib/kofficeui -I../../../lib/kofficeui -I../../../lib/kofficecore -I../../../lib/kofficecore -I../../../lib/store -I../../../lib/store -I../../../lib/kwmf -I../../../lib/kwmf -I../../../lib/kopalette -I../../../lib/kopalette -I../../../lib/interfaces -I../../../lib/kopainter -I../../../lib/kopainter -I/opt/trinity/include -I/opt/tqt3/include -I. -include tqt.h -DQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -fno-builtin -g3 -fno-inline -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -I/usr/include/tqt -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DHAVE_KNEWSTUFF -fexceptions -MT kis_png_converter.lo -MD -MP -MF .deps/kis_png_converter.Tpo -c kis_png_converter.cc -fPIC -DPIC -o .libs/kis_png_converter.o In file included from kis_png_converter.cc:40:0: ../../../chalk/core/kis_layer.h:170:34: warning: type qualifiers ignored on function return type [-Wignored-qualifiers] kis_png_converter.cc: In member function 'KisImageBuilder_Result KisPNGConverter::decode(const KURL&)': kis_png_converter.cc:233:97: error: invalid conversion from 'char**' to 'png_bytepp {aka unsigned char**}' [-fpermissive] /usr/include/png.h:2267:1: error: initializing argument 5 of 'png_uint_32 png_get_iCCP(png_const_structp, png_const_infop, png_charpp, int*, png_bytepp, png_uint_32*)' [-fpermissive] kis_png_converter.cc: In member function 'KisImageBuilder_Result KisPNGConverter::buildFile(const KURL&, KisPaintLayerSP, vKisAnnotationSP_it, vKisAnnotationSP_it, int, bool, bool)': kis_png_converter.cc:528:43: error: 'Z_DEFAULT_STRATEGY' was not declared in this scope kis_png_converter.cc:630:143: error: invalid conversion from 'char*' to 'png_const_bytep {aka const unsigned char*}' [-fpermissive] /usr/include/png.h:2274:1: error: initializing argument 5 of 'void png_set_iCCP(png_structp, png_infop, png_const_charp, int, png_const_bytep, png_uint_32)' [-fpermissive] kis_png_converter.cc:643:47: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] kis_png_converter.cc:649:53: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] kis_png_converter.cc:656:49: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] In file included from kis_png_converter.cc:793:0: kis_png_converter.cc: In member function 'KisImageBuilder_Result KisPNGConverter::decode(const KURL&)': kis_png_converter.cc:164:31: warning: ignoring return value of 'size_t fread(void*, size_t, size_t, FILE*)', declared with attribute warn_unused_result [-Wunused-result] make[4]: *** [kis_png_converter.lo] Error 1 make[4]: Leaving directory `/build/src/koffice/filters/chalk/png' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/build/src/koffice/filters/chalk' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/build/src/koffice/filters' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/build/src/koffice' make: *** [all] Error 2
Looks like kis_png_converter.cc needs patching. I'll see if I can figure it out based on the gwenview patch. I think that is all it needs. If anyone is good with this and can beat me to it, my hat is off to you.
And wow - processor speed really makes a huge difference in build times. For the packages I'm building on arch:
i686 build - old p4 2800
Build time 462 min. ~ 7.7 hours
x86_64 build - newer (but old) 9850 X4
Build time 224 min. ~ 3.7 hours
Never really built projects this large before, but speed -- does matter :)
koffice was building perfectly -- until it hit:
Yeah. Been there done that. :) I submitted a bug report to split the koffice package into smaller modules.
Looks like kis_png_converter.cc needs patching. I'll see if I can figure it out based on the gwenview patch. I think that is all it needs. If anyone is good with this and can beat me to it, my hat is off to you.
There was a patch to that same file 2012-01-11. I suspect the libpng 1.5 changes require a similar change.
http://www.trinitydesktop.org/patches/1326328201:b180811d9a814c638032f77aaf0...
And wow - processor speed really makes a huge difference in build times. For the packages I'm building on arch:
i686 build - old p4 2800
Build time 462 min. ~ 7.7 hours
x86_64 build - newer (but old) 9850 X4
Build time 224 min. ~ 3.7 hours
Never really built projects this large before, but speed -- does matter :)
Yes, speed is good for development but bad for users. Developers get accustomed to their scream demons and then forget to test on older hardware.
I have tried several times to use ccache to improve build times, but I never have gotten that process to work for me. I want to try distcc because I have two dual core machines here. I'm just not sure I want to burn the extra wattage.
If your new system is multi-core then use parallel processing. The general guideline is NUM_CORES + 1. I have a dual core and set NUMJOBS=-j3. My build scripts then run make $NUMJOBS.
Check the wiki but I believe only two packages fail to build with parallel processing: tdebindings and tdemultimedia.
Darrell
Darrell, David,
Number of cores tends to perform better -j4 for 4 cores. The +1 thing has been disputed numerous times :)
Calvin On Mar 30, 2012 12:37 AM, "Darrell Anderson" humanreadable@yahoo.com wrote:
koffice was building perfectly -- until it hit:
Yeah. Been there done that. :) I submitted a bug report to split the koffice package into smaller modules.
Looks like kis_png_converter.cc needs patching. I'll see if I can figure it out based on the gwenview patch. I think that is
all it
needs. If anyone is good with this and can beat me to it, my hat is off
to you.
There was a patch to that same file 2012-01-11. I suspect the libpng 1.5 changes require a similar change.
http://www.trinitydesktop.org/patches/1326328201:b180811d9a814c638032f77aaf0...
And wow - processor speed really makes a huge difference in build times. For the packages I'm building on arch:
i686 build - old p4 2800
Build time 462 min. ~ 7.7 hours
x86_64 build - newer (but old) 9850 X4
Build time 224 min. ~ 3.7 hours
Never really built projects this large before, but speed -- does
matter :)
Yes, speed is good for development but bad for users. Developers get accustomed to their scream demons and then forget to test on older hardware.
I have tried several times to use ccache to improve build times, but I never have gotten that process to work for me. I want to try distcc because I have two dual core machines here. I'm just not sure I want to burn the extra wattage.
If your new system is multi-core then use parallel processing. The general guideline is NUM_CORES + 1. I have a dual core and set NUMJOBS=-j3. My build scripts then run make $NUMJOBS.
Check the wiki but I believe only two packages fail to build with parallel processing: tdebindings and tdemultimedia.
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On 03/30/2012 09:50 AM, Calvin Morrison wrote:
Number of cores tends to perform better -j4 for 4 cores. The +1 thing has been disputed numerous times :)
OK 4 then :)
On 30 March 2012 12:24, David C. Rankin drankinatty@suddenlinkmail.com wrote:
On 03/30/2012 09:50 AM, Calvin Morrison wrote:
Number of cores tends to perform better -j4 for 4 cores. The +1 thing has been disputed numerous times :)
OK 4 then :)
-- David C. Rankin, J.D.,P.E.
If you are an octoput ( 8 hands, 8 cores ) and 9 balls to juggle, you'll be constantly switching one for another, while the other 7 work away steadily. With a computer it will constantly be switching between two processes, causing some overhead.
Calvin
If you are an octopus ( 8 hands, 8 cores ) and 9 balls to juggle, you'll be constantly switching one for another, while the other 7 work away steadily. With a computer it will constantly be switching between two processes, causing some overhead.
What an analogy! :)
Darrell
On 30 Mar 2012, Calvin Morrison spake thusly:
Darrell, David,
Number of cores tends to perform better -j4 for 4 cores. The +1 thing has been disputed numerous times :)
It also depends on hyperthreading, available memory, cache sizes, the cache-friendliness of the compiler (GCC really isn't cache-friendly at all) and a lot of other things.
On my hyperthreaded quad-core 2009-vintage Nehalem (256Kb K2 cache, 8Mb shared L3 cache), I benchmarked GCC 4.5 as taking least time with -j 12 (for a sizeable parallelizable compilation). But it has a hardware RAID array and 24Gb RAM, so it could easily keep up with those demands.
On 03/29/2012 11:36 PM, Darrell Anderson wrote:
If your new system is multi-core then use parallel processing. The general guideline is NUM_CORES + 1. I have a dual core and set NUMJOBS=-j3. My build scripts then run make $NUMJOBS.
That will be fun :) The 64 bit box is quad core so I'll try 5 :)
-
Calvin Morrison -
Darrell Anderson -
David C. Rankin -
Nix