On Thursday 25 September 2008 02:45:20 RW wrote:
> On Thu, 25 Sep 2008 01:00:07 +0200
>
> Mel <[EMAIL PROTECTED]> wrote:
> > Since it fails on the link, I wonder if the wrong linker is called by
> > ccache. I'll see what I can find out when it quiets down, right now
> > machine is under heavy load.
> >
> > (It might just be the path you set in /etc/profile. I use only
> > the /etc/make.conf version, not set the path additionally and
> > make -f /usr/src/Makefile.inc1 -V LIB32WMAKE shows it's mangeling the
> > path)
>
> world-cc does this:
>
> #!/bin/sh
> unset CCACHE_PATH
> export CCACHE_HASH_COMPILER
> exec /usr/local/libexec/ccache/cc "$@"
>
> So it unsets any ccache path variable set in /etc/profile.
Yes. But not PATH. I'm worried about PATH, not CCACHE_PATH.
From ccache-howto-freebsd.txt:
For Korn/Bourne shells Add the following to /etc/profile:
export PATH=/usr/local/libexec/ccache:$PATH
export CCACHE_PATH=/usr/bin:/usr/local/bin
I never set this bit as I don't want my path globally mangeled and still
ccache works correctly for ports:
# ccache -s
cache directory /var/db/ccache/root
cache hit 68324
cache miss 62348
called for link 5376
multiple source files 22
compile failed 1260
preprocessor error 1969
not a C/C++ file 1817
autoconf compile/link 14821
unsupported compiler option 1175
no input file 4364
files in cache 124696
cache size 2.1 Gbytes
max cache size 15.0 Gbytes
>
> For the benefit of anyone that didn't follow the previous thread, the
> issue was that in building 32-bit libraries under amd64, extra
> arguments get passed to the compiler inside the CC variable
> definition, hence the problem with overriding CC/CXX. I doubt that those
> updated make.conf settings have had much testing, they were just
> something suggested in a thread.
Yeah, same here. The only difference is that they look for ccache binary and
write the CC variable more fancy.
>
> BTW I would suggest CCACHE_HASH_COMPILER is set globally, otherwise
> building world invalidates any cache object built with the default
> compiler. Only having it on for world is the default, but it seems
> perverse to me - I see most of the benefit of ccache on port building.
Well, you can use world-cc for ports, like I do:
.if
(!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*) ||
!empty(.CURDIR:M/usr/ports*))
&& !defined(NOCCACHE)
CC=/usr/local/libexec/ccache/world-cc
CXX=/usr/local/libexec/ccache/world-c++
.endif
The only things that choke are things configured by devel/scons, tho I have to
find out why. I have it patched now by echo NOCCACHE=yes
>cat/offending_port/Makefile.local.
--
Mel
Problem with today's modular software: they start with the modules
and never get to the software part.
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
