View Full Version : HOWTO: FreeBSD with CCACHE
vermaden
November 16th, 2008, 22:53
install ccache port or add a package:
# cd /usr/ports/devel/ccache && make install clean
# pkg_add -r ccache
add the following to /etc/make.conf:
.if !defined(NO_CCACHE)
CC= /usr/local/libexec/ccache/world-cc
CXX= /usr/local/libexec/ccache/world-c++
.endif
.if ${.CURDIR:M*/ports/devel/ccache}
NO_CCACHE= yes
.endif
add the following to /.cshrc:
# set ccache varibles
setenv PATH /usr/local/libexec/ccache:$PATH
setenv CCACHE_PATH /usr/bin:/usr/local/bin
setenv CCACHE_DIR /var/tmp/ccache
setenv CCACHE_LOGFILE /var/log/ccache.log
# set ccache temp size to 512MB (default 1GB)
if ( -x /usr/local/bin/ccache ) then
/usr/local/bin/ccache -M 512m > /dev/null
endif
logout and login again before using ccache because when You dont ccache will use /root/.ccache dir instead of /var/tmp/ccache.
ccache can be shared between several computers the same as ports tree for example, check man ccache for more info.
ADDED 2007.2.15:
example ccache stats from my box.
% ccache -s
cache directory /var/tmp/ccache
cache hit 18562
cache miss 102820
called for link 9824
multiple source files 75
compile failed 1610
preprocessor error 1446
not a C/C++ file 3747
autoconf compile/link 16982
unsupported compiler option 511
no input file 6698
files in cache 49631
cache size 464.3 Mbytes
max cache size 512.0 Mbytes
ADDED 2007.2.16:
comparasion of buildworld times with and without ccache:
# without ccache
make -j1 buildworld 4148.38s user 937.02s system 97% cpu 1:27:00.40 total
# with ccache
make -j1 buildworld 1043.30s user 703.76s system 88% cpu 32:50.02 total
If you face a problem with /root/.ccache being used instead of /var/tmp/ccache then you may solve it that way:
% cd /home/${USER}
% rm -rf .ccache
% ln -s /var/tmp/ccache .ccache
% ls -l .ccache
lrwxr-xr-x 1 ${USER} ${USER} 15 Dec 19 15:20 .ccache -> /var/tmp/ccache
% ccache -s
cache directory /var/tmp/ccache
cache hit 165292
cache miss 327142
called for link 38002
multiple source files 216
compile failed 5182
preprocessor error 4934
couldn't find the compiler 1
not a C/C++ file 26249
autoconf compile/link 52665
unsupported compiler option 1379
no input file 23289
files in cache 79438
cache size 530.2 Mbytes
max cache size 512.0 Mbytes
% sudo ccache -s
cache directory /home/vermaden/.ccache
cache hit 165292
cache miss 327142
called for link 38002
multiple source files 216
compile failed 5182
preprocessor error 4934
couldn't find the compiler 1
not a C/C++ file 26249
autoconf compile/link 52665
unsupported compiler option 1379
no input file 23289
files in cache 79438
cache size 530.2 Mbytes
max cache size 512.0 Mbytes
kamikaze
November 17th, 2008, 09:19
<shameless advertising>
I'm using buildflags from sysutils/bsdadminscripts to do that. It also deals with using both, ccache and distcc at the same time.
</shameless advertising>
I have come to the conclusion that the default cache size of 1GB is way too low. At the moment I'm using 4GB:
# ccache -s
cache directory /root/.ccache
cache hit 607814
cache miss 993734
called for link 76913
multiple source files 316
compile failed 11642
preprocessor error 7718
couldn't find the compiler 4
not a C/C++ file 90356
autoconf compile/link 97184
unsupported compiler option 14339
no input file 29725
files in cache 269281
cache size 3.6 Gbytes
max cache size 4.0 Gbytes
As you can see I have a hit rate of ~38%, which is a pretty impressive number, I think. I don't know how mature that previous example is (ccache has to be in use for some time to bring benefits), but the shown 512MB cache only has a hit rate of ~15%
vermaden
November 17th, 2008, 09:43
<shameless advertising>
I'm using buildflags from sysutils/bsdadminscripts to do that. It also deals with using both, ccache and distcc at the same time.
</shameless advertising>
I have come to the conclusion that the default cache size of 1GB is way too low. At the moment I'm using 4GB (...) As you can see I have a hit rate of ~38%, which is a pretty impressive number, I think. I don't know how mature that previous example is (ccache has to be in use for some time to bring benefits), but the shown 512MB cache only has a hit rate of ~15%
Thanks for tips, propably it was used for short period of time, the last stats from my post give these stats with 512MB size:
cache hit 165292
cache miss 327142
About 33% so not so bad.
kamikaze
November 17th, 2008, 10:10
More than 30% is very decent. Compiling OpenOffice would blow your cache apart, though. Everything useful would be flushed out. OpenOffice is the reason I stepped from 1GB to 4GB.
vermaden
November 17th, 2008, 10:16
Compiling OpenOffice is like suicide, I always use packages for such big blobs like that ;)
kamikaze
November 17th, 2008, 10:27
You normally have to wait for a long time for new OOo packages. That's why I build them myself and share them.
vermaden
November 17th, 2008, 10:52
Propably I do not use OpenOffice that much to care about newest version, current 2.4 version seems to work fine.
Where do you keep your builds mate?
Maybe I will try them some day.
kamikaze
November 17th, 2008, 11:05
http://wiki.bsdforen.de/anwendungen/openoffice_aus_inoffiziellen_paketen
I've switched over to 3, because it doesn't have the font rendering problems of the 2-branch.
Weaseal
January 2nd, 2009, 02:15
Is there an ad-hoc way to disable CCACHE? For example, something like: make install clean WITHOUT_CCACHE=yes
vermaden
January 2nd, 2009, 02:44
like that mate:
# make NO_CACHE=yes install clean
kegf
January 14th, 2009, 08:15
change
.if !defined(NO_CACHE)
CC= /usr/local/libexec/ccache/world-cc
CCX= /usr/local/libexec/ccache/world-cc++
.endif
.if ${.CURDIR:M*/ports/devel/ccache}
NO_CCACHE= yes
.endif
to
.if !defined(NO_CACHE)
CC= /usr/local/libexec/ccache/world-cc
CCX= /usr/local/libexec/ccache/world-c++
.endif
.if ${.CURDIR:M*/ports/devel/ccache}
NO_CCACHE= yes
.endif
vermaden
January 14th, 2009, 08:48
@kegf
Thanks.
Mel_Flynn
February 13th, 2009, 21:30
Add a note:
You have to reinstall devel/libtool15 if it's installed, as changing CC/CXX will screw things up for it.
Adding the PATH change is not required and can create problems with lang/gcc* ports as dependencies, as it will add gcc## to $PATH and BUILD_DEPENDS will think it's installed, but once compilation starts it doesn't work.
I use:
:setenv=....<stripped other stuff>,CCACHE_DIR=/var/db/ccache/$:
in /etc/login.conf to make CCACHE_DIR independant of shell semantics and dot.profile files.
Finally the stats from my package builder:
cache directory /var/db/ccache/root
cache hit 508615
cache miss 379447
called for link 66381
multiple source files 228
compile failed 13214
ccache internal error 2
preprocessor error 21943
not a C/C++ file 27067
autoconf compile/link 118453
unsupported compiler option 6337
no input file 38147
files in cache 650587
cache size 8.6 Gbytes
max cache size 10.0 Gbytes
dennylin93
July 27th, 2009, 13:57
.if !defined(NO_CACHE)
CC= /usr/local/libexec/ccache/world-cc
CCX= /usr/local/libexec/ccache/world-c++
.endif
A small question. It is CCX or CXX? In /usr/local/share/doc/ccache/ccache-howto-freebsd.txt, is's CXX.
vermaden
July 27th, 2009, 14:15
Its CXX.
Artefact2
July 27th, 2009, 23:38
Thanks for this tip.
A little precision : if you use a non-csh shell, you have to edit the rc file of your shell, not /.cshrc. The syntax might change (export instead of setenv, ...).
vermaden
July 28th, 2009, 07:01
@Artefact2
That's obvious, but thanks for pointing it out.
graudeejs
August 22nd, 2009, 20:17
My Stats:
I build OpenOffice.org-3.1 uncached (with ccache on) in about 10-11 hours
It took about 3h 40min to compile OOO3.1 when it was cached in ccache :)
My PC:
Pentium 4 HTT @ 3GHz
RAM: 2.5GB @ 400Mhz
on GELI encrypted zpool :)
killasmurf86 $ ccache -s
cache directory /var/db/ccache
cache hit 79143
cache miss 139100
called for link 14059
multiple source files 75
compile failed 3599
ccache internal error 1
preprocessor error 2494
couldn't find the compiler 2
not a C/C++ file 7095
autoconf compile/link 28680
unsupported compiler option 932
no input file 10850
files in cache 278200
cache size 2.6 Gbytes
max cache size 4.0 Gbytes
nal
September 26th, 2009, 21:38
# Allow CCACHE for PORTS only (the buildworld has error with CCACHE)
.if ${.CURDIR:M*/ports*}
.if exists(/usr/local/libexec/ccache/world-cc) && !defined(NO_CCACHE)
CC=/usr/local/libexec/ccache/world-cc
CXX=/usr/local/libexec/ccache/world-c++
.endif
CFLAGS= ...
CXXFLAGS=${CFLAGS}
...
...
.endif
Seeker
April 12th, 2010, 22:41
like that mate:
# make NO_CACHE=yes install clean
A lots of luniz here will just copy-paste it and hit a wall:
.if !defined(NO_CACHE)
CC= /usr/local/libexec/ccache/world-cc
CXX= /usr/local/libexec/ccache/world-c++
.endif
.if ${.CURDIR:M*/ports/devel/ccache}
NO_CCACHE= yes
.endif
vermaden
April 12th, 2010, 22:50
@Seeker
Thanks, its also funny how long it was here without notifying ;)
mfaridi
June 13th, 2010, 07:03
my apace of /var is limit and I use this command portmaster -D -r -w gettext and I see ccache take many space of /var what happen when I delete all files in ccache folder , because I do not have many space ?
dennylin93
June 13th, 2010, 09:30
Simply limit the size of your cache using ccache -M
If you delete the files, your cache will be empty.
Slade
August 9th, 2010, 07:26
I'm wondering how I would go about using a new version of gcc (gcc45) with ccache. Right now I have just gcc45 running per the instructions at: http://www.freebsd.org/doc/en/articles/custom-gcc/article.html
That works fine but how would I go about getting ccache to use that. It seems like the instructions are for the standard version of gcc that comes with FreeBSD.
My current /etc/make.conf
.if !empty(.CURDIR:M/usr/ports/*) && exists(/usr/local/bin/gcc45)
CC=gcc45
CXX=g++45
CPP=cpp45
CPUTYPE?=amd64
.endif
my current /etc/libmap.conf
libgcc_s.so.1 gcc45/libgcc_s.so.1
libgomp.so.1 gcc45/libgomp.so.1
libobjc.so.3 gcc45/libobjc.so.2
libssp.so.0 gcc45/libssp.so.0
libstdc++.so.6 gcc45/libstdc++.so.6
I've tried looking over the examples in this thread and the ccache-howto-freebsd.txt when I installed ccache from ports but I just don't know enough about the make process to figure out how to get it working with gcc45.
oliverh
August 9th, 2010, 14:16
Using e.g. USE_GCC= 4.5+ is sufficient to my understanding.
According to http://ftp2.pl.freebsd.org/pub/FreeBSD/FreeBSD-current/ports/Mk/bsd.gcc.mk
camelia
August 9th, 2010, 17:42
BTW, I'd suggest using `?=' everywhere. It leaves the chance to override value from environ without touching make.conf.
As for port's gcc there are few pitfalls but libmap.conf addresses only runtime linking problem completely avoiding build linking one (rtld vs. ld (http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/148196)). BTW, using CPUTYPE?=native should work for any GCC (newer than gcc3*) and clang. If you're after more portable binaries then you'd want to use -mtune=generic but there is no make macro for it.
Seeker
September 1st, 2010, 21:18
I have 2 questions:
1) Why exactly, do we have to recompile, devel/libtool22, after we change CC and CXX? What are the consequences, of not doing so?
2) WITH ccache, I did a buildkernel and it took 43 min, to finish. Without ccache it took 39 min, to finish.
Then mistakenly, I've issued a same command again and ONLY then it did compiled in 9 minutes!
So, this means that ccache, speeds up RE-compilation, not a initial compilation, which can be even slower!
Now, as far as I know for myself, after build, I go for install.
I can't imagine, even one scenario, where I would go and build already build thing once again.
wblock@
September 2nd, 2010, 00:09
2) WITH ccache, I did a buildkernel and it took 43 min, to finish. Without ccache it took 39 min, to finish.
Then mistakenly, I've issued a same command again and ONLY then it did compiled in 9 minutes!
So, this means that ccache, speeds up RE-compilation, not a initial compilation, which can be even slower!
Same as a browser cache. The first time you go to that page, it's a little slower because it has to cache everything. Second time, it only retrieves the things that have changed, so it's faster. Yes, there's some added overhead in saving the cached files, but it's usually faster than retrieving them again.
Now, as far as I know for myself, after build, I go for install.
I can't imagine, even one scenario, where I would go and build already build thing once again.
When you buildworld or kernel, odds are good that a lot of it hasn't changed since the last time it was built, even weeks or months ago. How much has changed depends on how long it's been since you last built world. Next time you buildworld, time it again. If it takes less than 35 minutes (39 minutes normal minus the four already lost to overhead)... you win! After that, anything less than 39 minutes is pure win.
Seeker
September 2nd, 2010, 00:37
When you buildworld or kernel, odds are good that a lot of it hasn't changed since the last time it was built, even weeks or months ago. How much has changed depends on how long it's been since you last built world. Next time you buildworld, time it again. If it takes less than 35 minutes (39 minutes normal minus the four already lost to overhead)... you win! After that, anything less than 39 minutes is pure win.
Well I did timed it here and after initial kernel compilation of 43 min, RE-compilation was done in 9 min.
Which is almost, 5 times better, performance boost.
Even few months?!
In that time frame, I would do many, many compilations, of various ports, etc...
Perhaps, a dedicated HDD, just for CCACHE_DIR /var/tmp/ccache, would suffice? :P
vermaden
September 2nd, 2010, 06:48
@Seeker
These are mine ccache stats after about 12 months of usage:
% zfs list basefs/var/ccache
NAME USED AVAIL REFER MOUNTPOINT
basefs/var/ccache 575M 569G 575M /var/ccache
% ccache -s
cache directory /var/ccache
cache hit 17306
cache miss 43982
called for link 5148
multiple source files 5
compile failed 3107
preprocessor error 819
not a C/C++ file 3423
autoconf compile/link 3957
unsupported compiler option 1221
no input file 1343
files in cache 87964
cache size 1.1 Gbytes
max cache size 4.0 Gbytes
Also, if You limit it to 1GB in config, then it will STAY 1GB size.
ohauer
September 4th, 2010, 03:26
I can't imagine, even one scenario, where I would go and build already build thing once again.
Hm, think about you maintain some ports and you will test all different build options
or you patch parts of the source, generate the patchfiles and build again ...
With usage of CCACHE the configure scripts are the main bottleneck for me, and I have similar values like vermaden.
Nomacoro
September 4th, 2010, 11:58
i cant open the link. what is the matter?
camelia
September 4th, 2010, 18:18
think about you maintain some ports and you will test all different build options
or you patch parts of the source, generate the patchfiles and build againMost of the time changing configure options affects config.h or CFLAGS that cause cache misses during build.
Beeblebrox
May 3rd, 2011, 19:22
I am using gcc45 for ports, native (gcc42) for source. Therefore the conditional statement in make.conf needs to be a little different for my setup. After some debugging, I seem to have found the correct settings for my make.conf
.if !empty{.CURDIR:M/usr/ports/*}
CC= /usr/local/libexec/ccache/world/gcc45
CXX= /usr/local/libexec/ccache/world/g++45
CFLAGS+= -mssse3
.else
CC= /usr/local/libexec/ccache/world/cc
CXX= /usr/local/libexec/ccache/world/c++
.endif
.if ${.CURDIR:M*/ports/devel/ccache}
NO_CCACHE= yes
CC= gcc45
CXX= g++45
CPP= cpp45
CFLAGS+= -mssse3
.endif
Check your /usr/local/libexec/ccache/world/ directory and make sure you have all of the above named files in the folder. These of course, are not files but soft-links to the ccache file in the same folder. If you do not have such links, create them (#ln -s) with the appropriate names specified here (ccache should have created them already though).
Whenever you change (upgrade) ccache versions or add a different compiler (say you switched form 4.5 to 4.6 or such) you must re-build devel/libtool, otherwise you will see "precompiler fails sanity check" messages.
qsecofr
May 6th, 2011, 01:26
I needed to edit /etc/make.conf as suggested by Beeblebrox:
CC= /usr/local/libexec/ccache/world/cc
CXX= /usr/local/libexec/ccache/world/c++
The original suggestion had dashes instead of forward slashes. Not sure if the original was a typo or worked as intended on author's system. I'm using FreeBSD 8.1-Release.
Also replies suggested building libtool15. I have a more recent version. Not sure if that needs rebuilding, but I did. Was there anything version-specific about that recommendation?
It would have been good if the HOWTO referenced /usr/local/share/doc/ccache/ccache-howto-freebsd.txt and explained any differences.
I agree with Seeker in that a distinction exists between compilation vs. re-compilation. I have no idea how many times I re-compile the same version of the same port. Not by intent anyway - I leave that decision up to portmaster and or make. But I'm hopeful the tool has finer granularity than just overall port version. I'll probably know the next time I upgrade KDE. Maybe.
wblock@
May 6th, 2011, 03:18
I agree with Seeker in that a distinction exists between compilation vs. re-compilation. I have no idea how many times I re-compile the same version of the same port. Not by intent anyway - I leave that decision up to portmaster and or make. But I'm hopeful the tool has finer granularity than just overall port version. I'll probably know the next time I upgrade KDE. Maybe.
Benchmark it. Set NO_CCACHE and time a build. Reboot to clear the filesystem cache, leave ccache enabled, and build it again. My guess for port updates is that ccache usually won't have it in the cache and will actually make port builds a little slower.
/usr/src doesn't change all that much from week to week, but there can still be a lot of cache misses caused by small changes.
vermaden
May 6th, 2011, 09:07
My guess for port updates is that ccache usually won't have it in the cache and will actually make port builds a little slower.
CCACHE is useful if you compile something at least TWO TIMES; the first time it's slower because it 'learns', the second and every other compile run is a lot faster. Not the first one.
wblock@
May 6th, 2011, 15:36
CCACHE is useful if you compile something at least TWO TIMES; the first time it's slower because it 'learns', the second and every other compile run is a lot faster. Not the first one.
Of course. But do you think the cached version of KDE will still be in the cache by the time the next version comes out? And how much of it will be valid because the source hasn't changed? If it's not in the cache or invalid, the overhead of ccache will slow you down, and I suspect that will be the case most of the time with ports. Maybe a really big cache size would help. ccache -s will tell the story.
vermaden
May 6th, 2011, 22:04
I would say that if you compile a lot and have a quite large ccache space (4-8G) then the more you compile, the faster it will be, at least I got that impression after longer usage. Currently I only use packages and compile as little as possible, so I do not even bother with setting up CCACHE anymore.
bbzz
November 11th, 2011, 00:33
I have a habit of compiling everything as soon as it's updated. When I'm building as root it works. When I'm building as user using sudo it never uses CCACHE.
The configuration for root is in ~/.cshrc. The configuration for user is in ~/.zshrc. The configuration is identical, minus shell semantics, and both point to same CCACHE location, /var/db/ccache. So the both $PATH are equal.
Since I use sudo with user to update ports and build, CCACHE is never used. What do I need to do to make this work?
p.s. great guide as always.
vermaden
November 11th, 2011, 01:39
Edit the /usr/local/etc/sudoers file and add needed variables that should be kept when using sudo(8), for example:
Defaults env_keep += "HOME PKG_PATH PKG_DBDIR PKG_TMPDIR TMPDIR PACKAGEROOT PACKAGESITE PACKAGES PKGDIR FTP_PASSIVE_MODE"
bbzz
November 11th, 2011, 01:59
Tried, but that doesn't help.
There is no update when I check cache with:
ccache -s
Whereas, when run as root it get updated.
EDIT: I just realized that when using sudo user uses /root/.ccache.
EDIT2: Hence, fixed! Thx.
graudeejs
November 11th, 2011, 08:30
That's because If you use shared ccache you'll probably have permissions issues
bbzz
November 11th, 2011, 15:15
I changed permissions there. For some reason it only works when configuration is defined in both my user's ~/.zshrc AND settings forwarded in visudo.
If it's only configured in ~/.zshrc, but not in visudo (CCACHE_PATH, CCACHE_DIR), it uses default /root/.ccache location. If it's only defined in root's ~/.cshrc and forwarded with visudo, (so nothing defined in user's ~/.zshrc), then it uses user's default location, ~/home/$user/.ccache.
I don't get this, but I got it to work.
graudeejs
May 1st, 2012, 22:59
install ccache port or add a package:
.if !defined(NO_CCACHE)
CC= /usr/local/libexec/ccache/world-cc
CXX= /usr/local/libexec/ccache/world-c++
.endif
This should be updated to
.if !defined(NO_CCACHE)
CC= /usr/local/libexec/ccache/world/cc
CXX= /usr/local/libexec/ccache/world/c++
.endif
wblock@
May 1st, 2012, 23:21
The port suggests
.if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*))
.if !defined(NOCCACHE)
CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1}
CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1}
.endif
.endif
graudeejs
May 2nd, 2012, 06:00
The port suggests
.if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*))
.if !defined(NOCCACHE)
CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1}
CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1}
.endif
.endif
Yes, btw, I use WRKDIRPREFIX=/usr/obj
When I used
if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj/usr/src*))
...
.endif
it (ccache) didn't work. Any idea why?
wblock@
May 2nd, 2012, 13:17
That line uses ccache only for building the system. That's pretty reasonable, it's rare that ccache will help with building ports.
.if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj/usr/src/*))
.if !defined(NOCCACHE)
CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1}
CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1}
.endif
.endif
So this is the correct way to specify ccache only for world building and not ports? Is there an optimum size for ccache maybe?
wblock@
May 2nd, 2012, 17:58
I've used sizes of 1G to 4G, and more really doesn't help. Either nothing major has changed in the source and it mostly comes from cache, or something major or minor has changed that invalidates all of the cache, and everything has to be rebuilt.
donduq
May 25th, 2012, 14:19
I'm a bit at a loss so please explain the following to me: how do I use ccache with clang for world and ports? I am aware that not all ports compile with clang so once I understand how to get it to work, I can find workarounds for ports that are not happy when they're being built with clang.
donduq
May 25th, 2012, 14:33
I'm a bit at a loss so please explain the following to me: how do I use ccache with clang for world and ports? I am aware that not all ports compile with clang so once I understand how to get it to work, I can find workarounds for ports that are not happy when they're being built with clang.
Shortly after asking this I took a leap of foo and am now trying to build world after the following steps.
Big fat red warning for info scavengers: I'm just posting what I am trying out; don't blindly follow these steps. I'm posting this so someone can review them.
cd /usr/local/libexec/ccache/world
ln -s ccache clang
ln -s ccache clang++
cd ..
ln -s /usr/local/bin/ccache clang
ln -s /usr/local/bin/ccache++ clang
Then I edited /etc/make.conf:
(...other stuff...)
CC=clang
CXX=clang++
CPP=clang-cpp
.if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*))
.if !defined(NOCCACHE)
CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1}
CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1}
CC:=${CC:C,^clang,/usr/local/libexec/ccache/world/clang,1}
CXX:=${CXX:C,^clang\+\+,/usr/local/libexec/ccache/world/clang++,1}
CCACHE_DIR:=/usr/sysccache
CCACHE_COMPRESS:=yes
CCACHE_COMPILERCHECK:=content
.endif
.endif
.if ${CC:T} == "clang"
CFLAGS+= -Qunused-arguments
.endif
We'll see how it goes... but (wo)men of wisdom, please shine your light on this.
donduq
June 2nd, 2012, 15:45
Replying to my own comment... again. :stud
The system has been running for a week now. A little background information: it is a rented VPS, FreeBSD runs as a Xen HVM domU. It has 512M of RAM and one CPU core. Purpose of the VPS: to run Apache and Redmine.
Good news first: everything builds except for the Midnight Commander (mc). I could compile the many ports required by me and/or Redmine.
But the bad news: The system is painfully slow. I'm puzzled because the box seems to be healthy as can be seen in the following snippet from top:
CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
Mem: 172M Active, 144M Inact, 139M Wired, 18M Cache, 59M Buf, 4860K Free
Swap: 3072M Total, 896K Used, 3071M Free
See? This is when the system is idle, no one is using Redmine today. But when I go there to edit things or add new things I do notice a painful delay.
What I'm going to do now is this: recompile everything with gcc and test it again. If it is just as slow then we can assume that clang is not to blame. But if it is faster then something is up. Unfortunately I am not a C programmer or capable system engineer in these matters, so I can't be of much help beyond posting my own findings.
I would welcome feedback though. :f
vBulletin® v3.8.7, Copyright ©2000-2013, vBulletin Solutions, Inc.
0