[Libreoffice] First build resumed but failed on incomplete dependancies

Christian Lohmaier lohmaier+libreoffice at googlemail.com
Sat May 7 01:48:32 PDT 2011


Hi Peter, *,

On Sat, May 7, 2011 at 5:11 AM, Peter Teeson <peter.teeson at bell.net> wrote:
> ........
>> 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?

Yes, the message text regardomg "is suitable" might be misleading
though, 3.1 /would/ be suitable, but at tthe time the check was added
the latest version was 2.4. The version check was fixed/updated (that
is Thorsten's fix Michael was referring to earlier)
But even if it would have passed the version check, it would still
check whether it is actually used.
I.e. in the 3.4 branch, it would print
checking whether version of ccache is suitable... yes
checking whether ccache is actually used for the build... no, will not
enable --ccache-skip

But the outcome is the same: ccache-skip will not be enabled.

> 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

No - you would have to set those before running autogen.sh /
configure, otherwise the "is ccache used" will not be able to detect
it automatically. (but for ccache version 3.1 and newer it doesn't
make a difference, as those versions don't need the ccache-skip
anymore in this case)

> 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?

Actually: No. I would have expected that yours get overriden with
those that are defined in the MacOSXX86Env.set.sh - as that one does a
"export CC..."
So when you want to change variables after running configure, those
have to be changed /after/ sourcing the environment file.

> 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

OK, then the default has been increased in the meantime - good to know :-)

> <snip>
> USE_CCACHE is in the unset list
> So far so good. Next I did

Yes, so configure did everything correct :-)

> 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?

Yes - congratulations to your first build :-)
issue "ccache -s" and it should now show many files (as you did set CC
/ CXX to "ccache <compiler>", so your next build should be much faster
(depending on disk I/O it can easily be twice as fast)

> =============
> Building module instsetoo_native
> =============

this is the very last module, when everything has been compiled, this
module will just assemble the files to an installationset /
installable tree

> No EPM: do no packaging at this stage

As you didn't use --enable-epm, it won't create dmg packages, but

> Multiprocessing build is finished

the build did succeed :-)

> 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

Hmm - that number is low with only --disable-mozilla, I'd expect about
twice those files.. Did you also use --disable-binfilter?
(or of course if you continued with the tree that did previously fail,
the stuff that already has been compiled before the failure will not
be recompiled again, so probably all OK here :-)  but next time will
not yet be blazingly fast, because the already-compiled stuff has not
been cached yet.

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

Hack on! :-)

As you can successfully build now, look for one of the EasyHacks (or
whatever bothers you), modify the code and post your first patch to
the list :-))

ciao
Christian


More information about the LibreOffice mailing list