I think that the way the ccache package is currently installed in the /usr/bin/ccache directory is not a good way to do things for a couple reasons: 1. The ccache binary is not on the path by default -- it should really be in /usr/bin so it is available even when its "wrapper" symlinks are not. 2. The ccache subdir is in a directory on the path with the same name as the executable -- this can cause confusion for simplistic programs that don't stat the file. I'd like to suggest that the "wrapper" symlinks be installed either into /usr/lib/ccache/bin (my preference) or /usr/bin/ccache.links. With this done, the ccache binary can be put in /usr/bin. I've created an updated ebuild that implements the /usr/lib/ccache/bin setup. The install ensures that the old /usr/bin/ccache dir doesn't get in the way of the new executable, it ensures that the wrapper symlinks get removed on uninstall and it ensures that the symlink's directory doesn't vanish on re-install (by using a .keep file). Anyone installing this ebuild should edit /usr/lib/portage/bin/ebuild.sh and change the /usr/bin/ccache directory references to /usr/lib/ccache/bin (in 2 places). Reproducible: Always Steps to Reproduce:
Created attachment 7915 [details] The aforementioned ccache ebuild.
Created attachment 7916 [details] The aforementioned ccache ebuild.
i dont see the advantage of your way over the current setup ...
The main advantage is that the ccache executable gets to live in /usr/bin where it belongs. This separates being able to use ccache (by name) from using cache's compiler-cloaking symlinks (without having to resort to using fully- qualified pathnames). And someone who doesn't have /usr/bin/ccache on their path can still easily get stats or tweak the expiration settings because the ccache command is right there on the path. With the current setup you either get both the ccache command and the compiler-cloaking, or you get neither (or you have to type full pathnames or setup aliases or something -- all things that are less convenient than they need to be). The other advantage is one of athestics and (possibly) FHS compliance. Are their any other packages that put a subdir into /usr/bin? I know that the Filesystem Hierarchy Standard says that there must be no subdirs in /bin, but it doesn't say one way or the other about /usr/bin. I personally would avoid this, but if that's where you want it to go, having the subdir named something like ccache.links allows you to still place the ccache executable into the /usr/bin dir. One last thought: keep in mind that there is more to compiling than just ebuilds. The current system automates the use of ccache with ebuilds while making it difficult to type the ccache command. I'd like to see the same ebuild integration with an easy-to-type ccache command.
Created attachment 8094 [details] Fixed ccache reinstall bug with symlinks Zach Welch pointed out that the symlinks on my distcc ebuild were not surviving a re-install, and this bug affects my ccache ebuild too. I've taken Zach's fix from distcc and used it in this r2 ebuild. NOTE: when updating to this ebuild, either unmerge the old ccache version before you merge this version, OR merge it twice -- this will work around the bug in the r1 release where it was being overly agressive about removing the wrapper symlinks.
For what it's worth, I endorse these changes for several reasons: 1) it provides better compatibility for all users 2) it mimics the structure now used by distcc, which was adopted for many of these same reasons. 3) portage-2.0.46-r11 and later have support for these changes. Search for /usr/lib/ccache/bin in ebuild.sh for yourself 4) I've been involved with the process, so I'm both biased and knowledgable. Take both bits as grains of salt. I'd be happy to do the leg work to check in this new version as part of my distcc check-in for bug 13897. Wayne has also mentioned that he may have unified colorgcc along these same lines.
Since Ryan has many other things to do, I'll take this one off his hands, as the changes here complement the new distcc well and are already supported by Portage versions 2.0.46-r11 and later.
I have committed an updated ebuild that incorporates some of the recent changes to distcc, including a ccache-config script that manages the symlinks in /usr/lib/ccache/bin.
I got this in my morning's bit of upgrades and it was broken in two separate ways, so I decided to mask it again until resolved, since it seems probable at least one of these issues won't be my local to my system :-) 1) For some reason (don't know why yet, but haven't tested much) all standard configure scripts hang when trying to check 'g++ --version' - that's the last line in config.log but there's no test result, and then the script just sits there using 100% cpu. To be investigated. 2) When merging 2.1.1 over 2.1.1-r2 I got this: >>> Merging dev-util/ccache-2.1.1 to / --- /usr/ --- /usr/bin/ !!! Failed to move /usr/bin/ccache to /usr/bin/ccache.backup !!! [Errno 21] Is a directory bak /usr/bin/ccache /usr/bin/ccache.backup Traceback (most recent call last): File "/usr/bin/emerge", line 1610, in ? mydepgraph.merge(mydepgraph.altlist()) File "/usr/bin/emerge", line 954, in merge retval=portage.doebuild(y,"merge",myroot,edebug) File "/usr/lib/python2.2/site-packages/portage.py", line 1357, in doebuild return merge(settings["CATEGORY"],settings["PF"],settings["D"],settings["BUILDDIR"]+"/build-info",myroot,myebuild=settings["EBUILD"]) File "/usr/lib/python2.2/site-packages/portage.py", line 1489, in merge return mylink.merge(pkgloc,infloc,myroot,myebuild) File "/usr/lib/python2.2/site-packages/portage.py", line 3990, in merge return self.treewalk(mergeroot,myroot,inforoot,myebuild) File "/usr/lib/python2.2/site-packages/portage.py", line 3702, in treewalk if self.mergeme(srcroot,destroot,outfile,secondhand,"",cfgfiledict,mymtime): File "/usr/lib/python2.2/site-packages/portage.py", line 3870, in mergeme if self.mergeme(srcroot,destroot,outfile,secondhand,offset+x+"/",cfgfiledict,thismtime): File "/usr/lib/python2.2/site-packages/portage.py", line 3870, in mergeme if self.mergeme(srcroot,destroot,outfile,secondhand,offset+x+"/",cfgfiledict,thismtime): File "/usr/lib/python2.2/site-packages/portage.py", line 3858, in mergeme os.mkdir(mydest) OSError: [Errno 17] File exists: '/usr/bin/ccache' Seems as if portage moves files about to be overwritten to *.backup before actually removing them, and fails to do so in this case. This is probably a portage bug if that's so. I'll see if I can catch carpaski and ask him about that.
I really do not understand what is going on here. I've made an empty ebuild that just calls /usr/bin/g++ --version - that's the real g++, not the ccache wrapper! - and it hangs if ccache 2.1.1-r2 is installed, but runs ok with 2.1.1. How can this be? How can ccache affect the real g++'s behaviour?! Yet that's what I'm seeing... This is gcc-3.2.2-r1 on ~x86...
what version of portage do you have danamark ? thats a portage error btw and should be reported in a sep report ... but ive seen that bug before and it should be fixed now ...
Dan, I am running this version on several machines (x86 and ARM) with none of the problems you have reported. I have fixed the 'multiple installs' problem with the ebuild, though portage is still not clever enough to install a file over a previously installed and non-empty directory. As for your lockups... Are you setting CC/CXX or PATH with portage? That's a sure fire way to break things, and one which still needs be fully addressed. If trying a non-portage build, only PATH should be adjusted - CC/CXX should *never* be set. Finally, I have added a DEPEND for portage to ensure the latest versions are being pulled in. I have had other reports of this new version working, so I'm not entirely convinced that the program is broken versus there being some strange problem with your setup.
I got the same error: >>> Install ccache-2.1.1 into /var/tmp/portage/ccache-2.1.1/image/ category dev-util man: strip: /var/tmp/portage/ccache-2.1.1/image//usr/bin/ccache/ccache >>> Completed installing into /var/tmp/portage/ccache-2.1.1/image/ >>> Merging dev-util/ccache-2.1.1 to / --- /usr/ --- /usr/bin/ !!! Failed to move /usr/bin/ccache to /usr/bin/ccache.backup !!! [Errno 21] Is a directory bak /usr/bin/ccache /usr/bin/ccache.backup Traceback (most recent call last): File "/usr/bin/emerge", line 1610, in ? mydepgraph.merge(mydepgraph.altlist()) File "/usr/bin/emerge", line 954, in merge retval=portage.doebuild(y,"merge",myroot,edebug) File "/usr/lib/python2.2/site-packages/portage.py", line 1357, in doebuild return merge(settings["CATEGORY"],settings["PF"],settings["D"],settings["BUILDDIR"]+"/build-info",myroot,myebuild=settings["EBUILD"]) File "/usr/lib/python2.2/site-packages/portage.py", line 1489, in merge return mylink.merge(pkgloc,infloc,myroot,myebuild) File "/usr/lib/python2.2/site-packages/portage.py", line 3990, in merge return self.treewalk(mergeroot,myroot,inforoot,myebuild) File "/usr/lib/python2.2/site-packages/portage.py", line 3702, in treewalk if self.mergeme(srcroot,destroot,outfile,secondhand,"",cfgfiledict,mymtime): File "/usr/lib/python2.2/site-packages/portage.py", line 3870, in mergeme if self.mergeme(srcroot,destroot,outfile,secondhand,offset+x+"/",cfgfiledict,thismtime): File "/usr/lib/python2.2/site-packages/portage.py", line 3870, in mergeme if self.mergeme(srcroot,destroot,outfile,secondhand,offset+x+"/",cfgfiledict,thismtime): File "/usr/lib/python2.2/site-packages/portage.py", line 3858, in mergeme os.mkdir(mydest) OSError: [Errno 17] File exists: '/usr/bin/ccache' ---------------------------- my emerge info: didi ccache # emerge info Portage 2.0.46-r12 (default-x86-1.4, gcc-3.2.2, glibc-2.3.2_pre1-r0) ================================================================= System uname: 2.4.20 i686 AMD Athlon(tm) XP 1800+ GENTOO_MIRRORS="ftp://ftp.tu-clausthal.de/pub/linux/gentoo/ ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo/ http://filepile.tiscali.de/mirror/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/config /opt/quake3/cpma/server.cfg" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="" USE="x86 apm avi crypt cups encode jpeg libg++ mikmod mpeg ncurses nls pdflib png qtmt quicktime spell truetype xml2 xmms xv zlib gtkhtml gdbm berkdb slang readline arts tetex aalib bonobo svga tcltk java mysql gpm tcpd pam esd imlib oggvorbis qt opengl mozilla gphoto2 snmp cdr ncures threads X alsa -motif kde 3dnow sdl perl python guile ruby libwww ssl gtk mmx ogg vorbis oss gif gnome gpg gd" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-mcpu=athlon-xp -march=athlon-xp -O3 -pipe" CXXFLAGS="-mcpu=athlon-xp -march=athlon-xp -O3 -pipe" ACCEPT_KEYWORDS="x86 ~x86" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="sandbox" ------------------------------------------- the ccache-2.1.1-r2.ebuild works fine, but emerge -up --deep world will downgrade to version ccache-2.1.1.ebuild that dont work.
stop reporting the portage error, it is a sep issue ... this bug is only for issues with using ccache
Okay, I've worked around the portage error that the ccache ebuild is choking on. Please test the latest revisions in portage, which should allow you to move back and forth freely between the 2.1.1 and 2.1.1-r2 installs.
Created attachment 8746 [details] New ebuild for ccache-2.2. Here's an ebuild for ccache 2.2. The only differences in the ebuild file are: 1. The Copyright year is updated. 2. The references to portage 2.0.X+ are changed to 2.0.46-r11+ And I'm included a new digest file, of course. Otherwise it is the same as the 2.1.1-r2 ebuild. Zach: you might just prefer to make these changes yourself, but I'll provide the tar file, just in case someone wants to unpack it into their /local/portage/dev-util dir.
I've added 2.2 to the tree, thanks Wayne. I'm going to send a note to -core and remove the package.mask later today.
OK. The other issue is probably a local problem of mine. I say that beacuse some other related problems have developed so that something is obviously broken in my setup, I'll search for it...
this has been fixed with ccache 2.2 for a while
