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. _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"