[Libreoffice] First build resumed but failed on incomplete dependancies

Peter Teeson peter.teeson at bell.net
Fri May 6 20:11:33 PDT 2011


Hi Christian,*:
Man you are so patient with me and I bow to you.
On 2011-05-06, at 4:37 PM, Christian Lohmaier wrote:
<snip>
> If that is all, you installed ccache, but no build will use it.
> 
> To use it you must either set symlinks of the compiler's name to
> ccache and put those links in a
> path that is searched before the real compiler (that is how I have it
> setup), or you need to set CC="ccache gcc-4.0" and CXX="ccache
> g++-4.0" It's described in the manpage.

At this stage I do not want to setup symbolic links. 
My own fun projects are not large enough to benefit.

What I did was an ./autogen.sh --with-max-jobs=8 --with-num-cpus=8 --disable-mozilla
the log shows this.....
........
........
checking whether we are allowed and able to use --ccache-skip... probing...
checking for ccache... /usr/local/bin/ccache
checking whether version of ccache is suitable... no
configure: ccache version 3.1.4 not accepted. See description for --enable-ccache-skip
.........
........
So it seems at though autogen doesn't like this version.
Is that what you expected?

The autogen produced a MacOSXX86Env.Set.sh file in libo
I edited that to set CC="ccache gcc-4.0" and CXX="ccache g++-4.0"
Then in Terminal I did  
source MacOSXX86Env.Set.sh
env

This showed up: CXX=ccache /usr/bin/g++-4.0
This did not:	   CC=ccache /usr/bin/g++-4.0

Did you expect this?

> Also for LO, you should increase the size of the cache from the
> default of 500MB to 1GB or more

ccache -s shows max cache size 1.0 Gbytes 
man page says it's default 
<snip>

> If after this configure run, MacOSX*Env.Set.sh contains export
> USE_CCACHE=TRUE, then it is a bug. If instead it is part of the "unset
> <lots of variables>" line, then the configure check is all OK, and the
> build should not fail like it did anymore.
USE_CCACHE is in the unset list

So far so good. Next I did 
make

This was really fun to watch in Activity Monitor as it sure made use of the 8 cores and 16 threads.
[As a former motorbike owner I think we "blued the pipes"]

This seems MAY have worked based on the tail of the log
What do you think?

=============
Building module instsetoo_native
=============
Entering /Users/pteeson/git/libo/instsetoo_native/inc_openoffice/windows/msi_languages
Entering /Users/pteeson/git/libo/instsetoo_native/inc_openoffice/unix


mkout -- version: 1.8
mkout -- version: 1.8
Entering /Users/pteeson/git/libo/instsetoo_native/util

find: /Users/pteeson/git/libo/translations/source/: No such file or directory
dmake:  makefile.mk:  line 231:  Warning: -- Prior to dmake 4.5 only one
%-target per target-definition worked reliably. Check your makefiles.

dmake:  makefile.mk:  line 286:  Warning: -- Prior to dmake 4.5 only one
%-target per target-definition worked reliably. Check your makefiles.

No EPM: do no packaging at this stage

Multiprocessing build is finished
Maximal number of processes run: 8
Gandalf:libo pteeson$ 
Gandalf:~ pteeson$ ccache -s
cache directory                    	 /Users/pteeson/.ccache
cache hit (direct)                   	 5
cache hit (preprocessed)         2
cache miss                          	6468
called for link                      	198
compile failed                          6
unsupported compiler option   536
files in cache                     	17806
cache size                         	770.6 Mbytes
max cache size                     	1.0 Gbytes
Gandalf:~ pteeson$ 


Thanks to all for the great and patient help so far.
Where do we go from here?

respect....

Peter



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20110506/3572ffda/attachment.htm>


More information about the LibreOffice mailing list