compilercache-general Mailing List for compilercache
Brought to you by:
erikyyy
Menu
▾
▴
compilercache-general — general discussion
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(15) |
Nov
(3) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(2) |
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
|
From: Alexandre O. <ol...@ls...> - 2002-10-01 20:28:03
|
On Oct 1, 2002, Erik Thiele <er...@er...> wrote: > i am unsure what to do... maybe someone wants to take over the project > leadership. Perhaps you could just recommend people to switch to Tridge's ccache instead? It even acknowledges being based on the idea you came up with. Even though I initially opposed it, and deemed it mostly useless, now I've become hooked to compilercache and, more recently, ccache, that I can't live without these tools any longer :-) This is a public `thank you' for going ahead with it despite all my negative feedback. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer |
|
From: Erik T. <er...@er...> - 2002-10-01 18:59:44
|
On Tue, Oct 01, 2002 at 07:40:48PM +0200, Jochen Voss wrote: > Hi, > > On Wed, Jan 09, 2002 at 10:42:17PM +0100, Jochen Voss wrote: > > with the COMPILERNAMES variable it is not to hard to > > plug new compilers into compilercache. But still > > there is duplicated information: the compilernames are > > enumerated both, in the COMPILERNAMES variable and (as > > link names) in the COMPILERCACHEBINDIR directory. > > Just for completeness I add a patch to implement this: ... hi! some words from me again after a long period of time :-) the problem is, i am no student anymore. i am now working. usually very long per day. so after work i don't want to work again... not even on the compilercache. today our 5000 ampere transformer of the galvanic machinery started to burn which made me return 9 o'clock in the evening... having started at 7 o'clock in the morning this means effectivly no time for compilercache :) i know that my 1.0.10 version of the compilercache is stable and seems to make no problems. i also know about the "ccache", which is a port of the compilercache to the C language, which made it faster. there are also features added and some removed. i also know the debian version is changed relativly to mine. and there are several more people with private changes. so there are many "branches"... i am unsure what to do... maybe someone wants to take over the project leadership. but he has to keep the original idea. this compilercache shall be bugfree, simple, stupid. if you want to add ultra features, please do a branch. maybe compilercache2. users don't want problems. speedup is not worth it, if it imposes trouble. i don't want to ever hear "better use the old 1.0.10 version, and not the 1.0.14 which causes too much trouble". keep that in mind and take over the project. i will brief you with some long standing things you gotta do to the compilercache project. small changes if you think about it. but always keep in mind the BUGFREENESS! cya! erik -- Name: Erik Thiele \\\\ Email: er...@er... o `QQ'_ WWW: http://www.erikyyy.de/ / __8 ' ` |
|
From: Jochen V. <vo...@ma...> - 2002-10-01 17:40:57
|
Hi, On Wed, Jan 09, 2002 at 10:42:17PM +0100, Jochen Voss wrote: > with the COMPILERNAMES variable it is not to hard to > plug new compilers into compilercache. But still > there is duplicated information: the compilernames are > enumerated both, in the COMPILERNAMES variable and (as > link names) in the COMPILERCACHEBINDIR directory. Just for completeness I add a patch to implement this: --- compilercache-1.0.10.orig/bin/compilercache +++ compilercache-1.0.10/bin/compilercache @@ -31,8 +31,7 @@ LINKOUTPUT=3D"no" PATH=3D"/bin:/usr/bin" COMPILERPATH=3D"/bin:/usr/bin" -COMPILERNAMES=3D"c++ g++ cc gcc" COMPILERCACHEBINDIR=3D"/usr/bin/compilercache" # source the systems global configuration file [ -f /etc/compilercacherc ] && source /etc/compilercacherc @@ -66,11 +65,9 @@ # determine compiler type COMP=3D"$(basename "$0")" COMPILERNAMEMATCHES=3Dno -for TESTCOMPILERNAME in $COMPILERNAMES; do - if [ "$TESTCOMPILERNAME" =3D "$COMP" ]; then - COMPILERNAMEMATCHES=3Dyes - fi -done +if test -L "$COMPILERCACHEBINDIR/$COMP"; then + COMPILERNAMEMATCHES=3Dyes +fi if [ "$COMPILERNAMEMATCHES" =3D no ]; then printf "unsupported compiler type\n" 1>&2 exit 1 It seems to work for me. Jochen --=20 http://www.mathematik.uni-kl.de/~wwwstoch/voss/ |
|
From: Andrew T. <tr...@sa...> - 2002-04-01 13:13:28
|
> I did read that in the manpage but being used to compilercache I started the > other way round. What are the disadvantages of the symlink method? Both methods work fine, it's just easier to choose when to use ccache and when not to use it if you use the prefix. Cheers, Tridge |
|
From: <Ulf...@t-...> - 2002-04-01 11:38:27
|
I got my hands on ccache-1.1 some 24 or 30 hrs ago... ...when the webpage still told me of 1.0 only but 1.1 was downloadable... On Mon, Apr 01, 2002 at 03:03:28AM -0800, Andrew Tridgell wrote: [[[...]]] > > I built the ccache-1.1-*_i386.deb for woody and tested it. [[[...]]] > Rusty Russell has already submitted ccache-1.2 for inclusion in > Debian. :-) But I'll never get an experienced debianizer if I cannot find a small project to start with... :-( > Meanwhile, I've released ccache-1.3. [[[...]]] Incredible speed of progress! Fine! > > I made the binary and the links drop into /usr/lib/ccache, [[[...]]] > > put /usr/lib/ccache into your PATH to be hit earlier than the compilers > > it shall wrap... > You can also use it as a prefix for your compiler. For example, set > "CC=ccache gcc" in your Makefile. Or use: > CC="ccache gcc" ./configure > for autoconf packages. I did read that in the manpage but being used to compilercache I started the other way round. What are the disadvantages of the symlink method? -- put your hands over your eyes jump out of the plane there is no pilot -- Laurie Anderson in 'from the air' on 'big science' |
|
From: Andrew T. <tr...@sa...> - 2002-04-01 11:02:20
|
Ulf, > Having read your info about ccache I was so curious about ccache that I > built the ccache-1.1-*_i386.deb for woody and tested it. A potato package > will follow if I get positive feedback on the woody package... Rusty Russell has already submitted ccache-1.2 for inclusion in Debian. I believe it should be in unstable soon. I've also noticed someone has added it to the FreeBSD ports collection. Meanwhile, I've released ccache-1.3. Version 1.3 includes a C/C++ unifier that gives the same effect as the unifier in compilercache, but is rewritten in a much faster fashion (it's about twice as fast as the flex based unifier in compilercache). > I made the binary and the links drop into /usr/lib/ccache, so using this > package is mostly like using the compilercace package for debian. i.e. put > /usr/lib/ccache into your PATH to be hit earlier than the compilers it shall > wrap... You can also use it as a prefix for your compiler. For example, set "CC=ccache gcc" in your Makefile. Or use: CC="ccache gcc" ./configure for autoconf packages. Cheers, Tridge |
|
From: <Ulf...@t-...> - 2002-04-01 10:47:24
|
On Sun, Mar 31, 2002 at 09:10:20PM -0800, Andrew Tridgell wrote: > Some of you may be interested in http://ccache.samba.org/ I definitely am! > ccache is a re-implementation of Erik's excellent compilercache > package in C. Indeed! compilercache was and is excellent. I compiled thousands of deb packages with compilercache and was happy with it! > It is much faster (more than a factor of 2) and has more features, > including automatic cache size management and statistics gathering. Having read your info about ccache I was so curious about ccache that I built the ccache-1.1-*_i386.deb for woody and tested it. A potato package will follow if I get positive feedback on the woody package... It can be found in the repository http://wild.borg-uv.org/dists/woody (-: your source has been assimilated, resistance was futile! :-) but it cannot be 100% perfect, it is a quickhack, it just works for me... If someone has a system to play "russian roullette" with, just try it, feedback is welcome as I'm not an experienced "debianizer"... I made the binary and the links drop into /usr/lib/ccache, so using this package is mostly like using the compilercace package for debian. i.e. put /usr/lib/ccache into your PATH to be hit earlier than the compilers it shall wrap... For now I'm not sure the email address mentioned in the deb will work, so be sure to note my address from this post somewhere. The owner of borg-uv.org is working on the mailer after a server cleanup and partial reinstall, so this is a known problem and will be solved within the next few days... ...and if someone knows a better manager for own repositories than debarchiver, please let me know too... -- # # Say it in Python ;-) # try: you.run(away) finally: borg.assimilate(you) |
|
From: Andrew T. <tr...@sa...> - 2002-04-01 05:09:13
|
Some of you may be interested in http://ccache.samba.org/ ccache is a re-implementation of Erik's excellent compilercache package in C. It is much faster (more than a factor of 2) and has more features, including automatic cache size management and statistics gathering. Cheers, Tridge |
|
From: Joe R. <ch...@no...> - 2002-01-10 08:42:31
|
applied is a patch, which implements (big word for small changes :)) a new behavior. i had the problem that i corrupted some cachefiles. as i didnt want to delete my precious compilercache i added a new feature: by setting KILLCOMPILERCACHE compilercache kills and then recreates the cashed files. no fiddling with timestamps to find the right files, just setting a variable. yours josef |
|
From: Jochen V. <jv...@we...> - 2002-01-09 21:43:54
|
Hello,
with the COMPILERNAMES variable it is not to hard to
plug new compilers into compilercache. But still
there is duplicated information: the compilernames are
enumerated both, in the COMPILERNAMES variable and (as
link names) in the COMPILERCACHEBINDIR directory.
My question is: is there any reason for this
duplication? Why not just use the links in
COMPILERCACHEBINDIR? The reasoning "if the link is
there, it will be a valid compiler name" sounds really
convincing, doesn't it?
What do you think,
Jochen
--=20
Omm
(0)-(0)
http://www.mathematik.uni-kl.de/~wwwstoch/voss/privat.html
|
|
From: Erik T. <er...@er...> - 2001-11-20 20:41:16
|
hi! On Tue, Nov 20, 2001 at 08:17:08PM +0100, Jochen Voss wrote: > Package: compilercache > Version: 1.0.9-2 1.0.10 is the new one? sorry i didn't check if .deb is available. i always didn't understand why software writers didn't even check their .debs if others make them for them, but nowadays as Jochen makes .debs for my software i understand why software developers don'T check them :) first it's extreme lazyness. that's probably the main reason. second i use my own installation, since that's what i always did with that software. third i update my code sometimes which would mean removal of the .deb. but mainly it's lazyness - shame on me :-) > Severity: normal change severity to wishlist or close the bug :-) > With 1.0.9-2, you (wisely) moved the cache directory to the user's > home directory to avoid security problems. However, some users will > still want to have the directory in /tmp so that cache entries are > expired automatically. If they do put the cache in /tmp, the patch > below will increase security by first creating the directory and then > checking whether it is owned by the user. i don't like this. in 1.0.10 you can configure where to put your cache data. nobody forces you to do anything in /tmp. but if you want to, you may do it. now the additional functionality must be activatable by a config option. because a user putting his cache in his home dir obviously does not want this kind of checking. so there's another new option, which i think is not useful and just confusing users. it's better to have private clean scripts that clean your own cache on a regular basis (cron or login) than to move the stuff to /tmp by force, no matter how complicated this is, just to have it automatically cleaned on boot. and by the way, cleaning the WHOLE cache on boot just sucks. what you really want is cleaning some week old cache entries. and not just a complete wipe out on reboot. so the extra effort seems to be useless. the private clean script stuff is in the todo for 1.0.11 > I believe this makes cache dirs in /tmp secure as long as the cache > dir is in /tmp itself (/tmp/compilercache_$USER) and not in a further > subdirectory (/tmp/somedir/compilercache_$USER). The worst thing that > can happen is a "denial of service" if someone else got there first > and created /tmp/compilercache_$USER files for all user names - not > really a problem in practice. maybe. but i don't see the point in putting the cache to /tmp. other cache programs like all internet proxies, e.g. squid don't put their cache in /tmp either. /tmp is for erase-on-reboot temporary files. cache entries are not erase-on-reboot temporary files. > This change breaks the ability to share a cache between >1 users. > However, that is evil anyway, not only for security reasons, but also > because all sorts of "funny" problems can arise by different toolchain > versions being used on different machines. this kind of "funny" thing cannot happen. the version of installed compiler is used in the cache file name computation. if multiple compilers with the same 'gcc -v' output produce different ".c" - ".o" pairs then something else is wrong, not the compilercache. as i am hearing this wrong argument very often i should emphasize it in the readme i guess... or in the FAQ maybe. i added it to my TODO. > [patch...] > What do you think about this? I think this > should not be implemented directly, because it > looses the possibility to share cache directories. > But maybe the best solution would be, to add a > new option to the configuration file: if you would > set YES_PLEASE_CHECK_THE_CACHE_DIR_OWNER=1, the > above check could be enabled, and be disabled otherwise. > So again, what do you think? i think that option is not neccesary. cu erik -- Name: Erik Thiele \\\\ Email: er...@er... o `QQ'_ WWW: http://www.erikyyy.de/ / __8 ' ` |
|
From: Jochen V. <vo...@ma...> - 2001-11-20 19:17:15
|
Hello,
I got the following bug report for my Debian package
of compilercache.
From: Richard Atterer <at...@de...>
Subject: compilercache: Insecure temporary directory creation
Date: Sun, 11 Nov 2001 19:05:58 +0100
Package: compilercache
Version: 1.0.9-2
Severity: normal
Tags: patch
Hi,
With 1.0.9-2, you (wisely) moved the cache directory to the user's
home directory to avoid security problems. However, some users will
still want to have the directory in /tmp so that cache entries are
expired automatically. If they do put the cache in /tmp, the patch
below will increase security by first creating the directory and then
checking whether it is owned by the user.
I believe this makes cache dirs in /tmp secure as long as the cache
dir is in /tmp itself (/tmp/compilercache_$USER) and not in a further
subdirectory (/tmp/somedir/compilercache_$USER). The worst thing that
can happen is a "denial of service" if someone else got there first
and created /tmp/compilercache_$USER files for all user names - not
really a problem in practice.
This change breaks the ability to share a cache between >1 users.
However, that is evil anyway, not only for security reasons, but also
because all sorts of "funny" problems can arise by different toolchain
versions being used on different machines.
--- compilercache.orig Sun Nov 11 18:36:54 2001
+++ compilercache Sun Nov 11 18:39:34 2001
@@ -107,6 +107,11 @@
exit 0
}
+if test ! -O "$CACHEDIR" -o ! -G "$CACHEDIR"; then
+ echo "compilercache: error: \`$CACHEDIR' owned by another user/group" 1>&2
+ exit 1
+fi
+
# bypass if user temporarily disabled compilercache
if ! [ "$NOCOMPILERCACHE" = "" ]; then
ignoremode "NOCOMPILERCACHE environment variable set"
Full details are at
http://bugs.debian.org/119170
What do you think about this? I think this
should not be implemented directly, because it
looses the possibility to share cache directories.
But maybe the best solution would be, to add a
new option to the configuration file: if you would
set YES_PLEASE_CHECK_THE_CACHE_DIR_OWNER=1, the
above check could be enabled, and be disabled otherwise.
So again, what do you think?
Jochen
--
http://www.mathematik.uni-kl.de/~wwwstoch/voss/
|
|
From: Mike A. H. <mh...@re...> - 2001-11-01 08:36:24
|
On Wed, 31 Oct 2001, Erik Thiele wrote: >i got a problem that drives me nuts. > >it's all about temporary files creation in bash scripts. >compilercache needs to do two things. > >1) create a temporary file that is maximally fast > >2) create a temporary file in the cache directory that can be renamed >to the real entry by a single atomic "rename" system call. (i.e. mv >needn't copy) this is important because otherwise other users of your >cache will get half-ready (i.e. wrong) .o files. > >debian has the nicest fix for this task. it's the "tempfile" >program. unfortunately it is not installed in other distributions like >redhat, or even other unixes. I do not know if debian has mktemp or not, but the standard way in Red Hat Linux and most other RPM based distro's is to use mktemp. TEMPFILE=$(mktemp "/tmp/somefile.XXXXXX") >in compilercache-1.0.9 i was using > >FASTTMPFILE=/tmp/compilercache_$$ > >which is a VERY severe security hole since other users could install >link files there and manipulate the temporary files of other users... Correct, and we are constantly tracking down these horrible security problems too. ;o( >there exists a "mktemp" program which is not portable to HP-UX at least. Yep, that is what we use. >ok. i NEED the functionality (especially the --directory parameter) of >debian "tempfile". mktemp -d >either it is there or not. if not, i must include a tempfile >program in the compilercache distribution and tell the user he >must install it. but where to ??? /bin is not an option for >non-root users. so the user must put it somewhere in his path >and set the PATH variable accordingly in the .compilercacherc >config file. but where will he put it ? in the compilercache >bin dir? mktemp sources are very very small, I'd just include it in its entirety, and by default install it into the compilercache dir. >and who writes the tempfile program? maybe a perl script? i wrote one, >(without the --directory functionality) but it is very slow: > >use File::Temp qw/tempfile/; >($fh,$filename)=tempfile(); >print $filename."\n"; > >and by the way.... the current 1.0.10 version fixes this problem in a >somehow funny way. you just set your own private temporary directory >and all problems are gone away. With mktemp being open source and written in C, it would be a better choice. Any perl script or other script is going to defeat a lot of the purpose of compilercache, which is speed. Hope this helps. ---------------------------------------------------------------------- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. Phone: (705)949-2136 http://www.redhat.com ftp://people.redhat.com/mharris Red Hat XFree86 mailing list: xfr...@re... General open IRC discussion: #xfree86 on irc.openprojects.org ---------------------------------------------------------------------- |
|
From: Erik T. <er...@er...> - 2001-10-31 13:21:27
|
hi. i got a problem that drives me nuts. it's all about temporary files creation in bash scripts. compilercache needs to do two things. 1) create a temporary file that is maximally fast 2) create a temporary file in the cache directory that can be renamed to the real entry by a single atomic "rename" system call. (i.e. mv needn't copy) this is important because otherwise other users of your cache will get half-ready (i.e. wrong) .o files. debian has the nicest fix for this task. it's the "tempfile" program. unfortunately it is not installed in other distributions like redhat, or even other unixes. in compilercache-1.0.9 i was using FASTTMPFILE=/tmp/compilercache_$$ which is a VERY severe security hole since other users could install link files there and manipulate the temporary files of other users... there exists a "mktemp" program which is not portable to HP-UX at least. ok. i NEED the functionality (especially the --directory parameter) of debian "tempfile". either it is there or not. if not, i must include a tempfile program in the compilercache distribution and tell the user he must install it. but where to ??? /bin is not an option for non-root users. so the user must put it somewhere in his path and set the PATH variable accordingly in the .compilercacherc config file. but where will he put it ? in the compilercache bin dir? and who writes the tempfile program? maybe a perl script? i wrote one, (without the --directory functionality) but it is very slow: use File::Temp qw/tempfile/; ($fh,$filename)=tempfile(); print $filename."\n"; and by the way.... the current 1.0.10 version fixes this problem in a somehow funny way. you just set your own private temporary directory and all problems are gone away. so.. i decided that 1.0.10 is a good version. even though i told some of you it's not good yet since i'll change the temp stuff again, but i guess i won't. security, anti-complexity and speed go first :) a note to the debian package maintainer of compilercache: you did the following patch in compilercache-1.0.9-2.deb: 283,286c277,278 < if ! TMPFILE=$(tempfile); then < echo "compilercache: error: cannot create temporary file" 1>&2 < exit 1 < fi --- > TMPFILE="$CACHEDIR/tmp_$(hostname)_$$" > rm -f "$TMPFILE" this opens a new bug. if you run two compilercaches at the same time on the same file and same user, one will write the .o file, the other one sees, ah it's already there and copies it. but as it is only half written, the second compiler will retrieve a half .o file only. TMPFILE will be mv'ed to the real cache entry. that must be an atomic operation. if /tmp is mounted on tmpfs for example and not your cache harddisk, mv won't be atomic and the above effect will occur. this problem does not exist in original 1.0.9 and in 1.0.10 since both have the temporary .o file in the cache directory. so... have fun with 1.0.10 :-) cu erik -- Name: Erik Thiele \\\\ Email: er...@er... o `QQ'_ WWW: http://www.erikyyy.de/ / __8 ' ` |
|
From: Erik T. <er...@er...> - 2001-10-30 22:07:30
|
hi. compilercache-1.0.10 is released. http://www.erikyyy.de/compilercache/ from the changelog: * fixed severe security problem in tempfile handling this will close the pending severity:grave debian bug report btw. the reason for not using "tempfile" is that other unixes unfortunately don't have it. * security note in README file about sharing cache directory among multiple users if multiple users share their cache directory they must trust each other, because user A can manipulate the compilation results of user B... * added the COMPILERNAMES configuration variable now parallel installation of nonstandard compilernames like gcc-3.0 together with the standard gcc,g++,* is supported easily. * added TEMPDIR configuration variable related to the fixed security problem... * changed CACHEDIR default value into home directory of the user /tmp gets cleaned on reboot. netscape cache is also not in /tmp :) * changed default SHALLDEBUG from "yes" to "no" some configure scripts were broken because they couldn't interpret compilercache debug output messages * removed the linkfiles from the distribution they are now generated by compile.sh that hopefully fixes all issues that have arised in the past :) sorry for long waiting time. have fun. cu erik -- Name: Erik Thiele \\\\ Email: er...@er... o `QQ'_ WWW: http://www.erikyyy.de/ / __8 ' ` |
|
From: Erik T. <er...@er...> - 2001-10-30 22:00:52
|
On Tue, Oct 30, 2001 at 11:45:04AM +0100, Jochen Voss wrote: > Hi, > > On Tue, Oct 30, 2001 at 09:45:04AM +0000, Robert McQueen wrote: > > ... You end up with multiple directories in > > /usr/lib/gcc-lib/i386-linux/ such as 2.95.4, and can use command line > > parameters to gcc to switch compiler versions. > > This case is no problem at all: to quote from the README file: > > But if I change compiler options like -D_REENTRANT_ or -O2 or -g ? > That's actually an easy point. compilercache puts the commandline > options also into the cache. If you use other commandline options, > recompilation will take place. > > So different command line options (e.g. to choose the > compiler version) will lead to different cache files. The > only problem is the case, when the same command line, say > "gcc -c test.c", suddenly should lead to different output, because > the default behaviour of gcc changed. no this is no problem since the output of "gcc -v" is also used for hash value computation. you'll never get the output of a gcc-1 compiler when compiling exactly the same file with exactly the same options but a gcc-2 compiler. > > Jochen > -- > http://www.mathematik.uni-kl.de/~wwwstoch/voss/ > > _______________________________________________ > Compilercache-general mailing list > Com...@li... > https://lists.sourceforge.net/lists/listinfo/compilercache-general -- Name: Erik Thiele \\\\ Email: er...@er... o `QQ'_ WWW: http://www.erikyyy.de/ / __8 ' ` |
|
From: Jochen V. <vo...@ma...> - 2001-10-30 10:45:11
|
Hi,
On Tue, Oct 30, 2001 at 09:45:04AM +0000, Robert McQueen wrote:
> ... You end up with multiple directories in
> /usr/lib/gcc-lib/i386-linux/ such as 2.95.4, and can use command line
> parameters to gcc to switch compiler versions.
This case is no problem at all: to quote from the README file:
But if I change compiler options like -D_REENTRANT_ or -O2 or -g ?
That's actually an easy point. compilercache puts the commandline
options also into the cache. If you use other commandline options,
recompilation will take place.
So different command line options (e.g. to choose the
compiler version) will lead to different cache files. The
only problem is the case, when the same command line, say
"gcc -c test.c", suddenly should lead to different output, because
the default behaviour of gcc changed.
Jochen
--
http://www.mathematik.uni-kl.de/~wwwstoch/voss/
|
|
From: Robert M. <rob...@de...> - 2001-10-30 10:16:31
|
On Tue, Oct 30, 2001 at 09:23:36AM +0100, Erik Thiele wrote: > i just think that the cost-benefit ratio is very very bad for things > like that. and after all, you don't really want to manually tweak the > cache and erase files for old compilers or stuff like that. you just > want everything to silently work without thinking about it. so even if > you COULD remove the files generated from deleted compilers, you > probably wouldn't do it, would you? You're making the mistaken assumption that just because you have a newer version of the compiler, the old one is no longer used. This is not the case. It is perfectly legitimate to have multiple gcc versions installed. You end up with multiple directories in /usr/lib/gcc-lib/i386-linux/ such as 2.95.4, and can use command line parameters to gcc to switch compiler versions. This is perfectly legitimate and useful if you're transitioning to GCC 3. Some programs don't build with GCC 3, some need to, and it's better not to build some with it (C++ is less efficient in 3 apparently) and the resulting .o files are different from both compilers. So there is a good argument for supporting hashing in the the compiler version to the file or filename, or just switching directory depending on compiler. > cu > erik Regards, Rob |
|
From: Erik T. <er...@er...> - 2001-10-30 08:24:19
|
hi On Wed, Oct 17, 2001 at 03:26:21PM +0200, Josef Radinger wrote: > Joachim Breitner wrote: > > > > Hi all, > > > > it's been a bit silent here. anyway, what about this: > > > > We save some additional Info, e.g. into the filename (l234k5j2l34j234-gcc-3.0.1-kernel-2.4.10), so that after a compilerupdate (which is due to end of Oct, gcc-3.0.2), an simple perlscript can clean up the files from a specific compilerversion. > > > > So, why not just delete all files when the new compiler arrives? Would work for me, but some want to keep two compilers at one (e.g. gcc-3.0.x and gcc-2.x), which can be pretty useful, since not all progs compile with the new gcc. Or with networked or shared cache, you can't just delete all files, but you CAN perhaps delete a specific compiler version. > > > > Another example would be optimizer flags. When I sell my athlon and buy a whatever comes next, I have no use for cached athlon-optimized files. > > > > What do you think? > > why not saving into different directories for different compilers? just because it's additional complexity and of virtually no use. think about it. you could do stuff like that everywhere in our computing world: i'll just create some examples: - the linux kernel could remove netscape from the buffer cache once galeon was installed by the user. - web proxies could put every webpage in a separate directory so that the user could delete a directory of his choice to save some bytes of disk space. - ... well. nothing more coming to my mind fast enough ;) i just think that the cost-benefit ratio is very very bad for things like that. and after all, you don't really want to manually tweak the cache and erase files for old compilers or stuff like that. you just want everything to silently work without thinking about it. so even if you COULD remove the files generated from deleted compilers, you probably wouldn't do it, would you? cu erik -- Name: Erik Thiele \\\\ Email: er...@er... o `QQ'_ WWW: http://www.erikyyy.de/ / __8 ' ` |
|
From: Erik T. <er...@er...> - 2001-10-30 08:16:03
|
hi! On Wed, Oct 17, 2001 at 12:00:00AM +0200, Joachim Breitner wrote: > it's been a bit silent here. anyway, what about this: :-) > We save some additional Info, e.g. into the filename > (l234k5j2l34j234-gcc-3.0.1-kernel-2.4.10), so that after a > compilerupdate (which is due to end of Oct, gcc-3.0.2), an simple > perlscript can clean up the files from a specific compilerversion. well. this would at least mean another file per .o file. or the .o file won't be a .o file anymore but for example a .tar archive with your information and a .o file in it. or a directory with your info and the .o file inside. but all those ideas don't seem to be real simple :) > So, why not just delete all files when the new compiler arrives? > Would work for me, but some want to keep two compilers at one > (e.g. gcc-3.0.x and gcc-2.x), which can be pretty useful, since not > all progs compile with the new gcc. Or with networked or shared > cache, you can't just delete all files, but you CAN perhaps delete a > specific compiler version. > > Another example would be optimizer flags. When I sell my athlon and > buy a whatever comes next, I have no use for cached athlon-optimized > files. > > What do you think? well. if you delete all files not accessed the last 10 weeks, the old stuff from old compilers will disappear automatically. your idea is like saying the web proxy cache should delete all webpages of provider A, if the user switched to provider B. but what happens in reality is the old stuff from provider A will be removed because nobody uses it anymore. i don't consider it a good idea to add complexity here. cu erik -- Name: Erik Thiele \\\\ Email: er...@er... o `QQ'_ WWW: http://www.erikyyy.de/ / __8 ' ` |
|
From: Jochen V. <jv...@we...> - 2001-10-28 22:48:57
|
Hello, I got a bug report for the debian package of compilercache. Compilercache creates files in /tmp in an insecure way. By creating symlinks a malicous user may trick you into overwriting any of your files. I append the bug report below. This should really be fixed. Jochen ----- Forwarded message from Eduard Bloch <bl...@de...> ----- Subject: Bug#117426: compilercache: insecure temp files From: Eduard Bloch <bl...@de...> To: Debian Bug Tracking System <su...@bu...> Date: Sun, 28 Oct 2001 20:15:16 +0100 Package: compilercache Version: 1.0.9-1 Severity: grave Tags: patch Justification: user security hole I just noticed that compilercache stores the tempfiles in /tmp. But it does either use really random names (*), nor does it check the files before writ= ting to them. This makes it possible for users to create symlinks to everything = they want and that file would be trashed. Or insert some malicious code in root's build. (*) It is very easy to prognose the filename since the PID is used. The fix is quite easy: use the $RANDOM variable like in the attached patch (this is still not very secure, but better than PID), or use `tempfile` for creating a uniq filename. 236c236 < FASTTMPFILE=3D/tmp/compilercache_$$ --- > FASTTMPFILE=3D/tmp/compilercache_$RANDOM Gruss/Regards, Eduard. ----- End forwarded message ----- |
|
From: Jochen V. <jv...@we...> - 2001-10-17 18:53:50
|
Hi,
in order to install gcc versions 2.9x and 3.x in parallel
some systems install the compilers under names like gcc-2.95
and gcc-3.0. To support explicit choice of the compiler
I suggest the following patch.
== patch starts at next line ===============================
--- compilercache~ Mon Sep 24 18:07:58 2001
+++ compilercache Wed Oct 17 20:43:23 2001
@@ -63,7 +63,9 @@
# determine compiler type
COMP="$(basename "$0")"
-if ! ( [ "$COMP" = gcc ] || [ "$COMP" = cc ] || [ "$COMP" = g++ ] || [ "$COMP" = c++ ] ); then
+if ! [ "$COMP" = cc -o "$COMP" = c++ \
+ -o "$COMP" = gcc -o "$COMP" = gcc-2.95 -o "$COMP" = gcc-3.0 \
+ -o "$COMP" = g++ -o "$COMP" = g++-2.95 -o "$COMP" = g++-3.0 ]; then
printf "unsupported compiler type\n" 1>&2
exit 1
fi
== patch ends at previous line =============================
Jochen
--
Omm
(0)-(0)
http://www.mathematik.uni-kl.de/~wwwstoch/voss/privat.html
|
|
From: Joachim B. <ma...@jo...> - 2001-10-17 14:07:59
|
At 15:26 17.10.01 +0200, Josef Radinger wrote: >Joachim Breitner wrote: >> >> Hi all, >> >> it's been a bit silent here. anyway, what about this: >> >> We save some additional Info, e.g. into the filename (l234k5j2l34j234-gcc-3.0.1-kernel-2.4.10), so that after a compilerupdate (which is due to end of Oct, gcc-3.0.2), an simple perlscript can clean up the files from a specific compilerversion. >> >> So, why not just delete all files when the new compiler arrives? Would work for me, but some want to keep two compilers at one (e.g. gcc-3.0.x and gcc-2.x), which can be pretty useful, since not all progs compile with the new gcc. Or with networked or shared cache, you can't just delete all files, but you CAN perhaps delete a specific compiler version. >> >> Another example would be optimizer flags. When I sell my athlon and buy a whatever comes next, I have no use for cached athlon-optimized files. >> >> What do you think? > >why not saving into different directories for different compilers? That would of course work for different Compiler versions, but what if you want to work with more than one criteria (e.g. arch)? And I think it's still easier for the script, if it finds all the files in one dir and the filenames starting with the md5sum. When the additional info is saved behind a dash or something, then the script itself can ignore it (it just has to add it when putting a new file into the cache). And for anther script it would still be easy to delete all files that mach certain criterias. So far so good, Joachim +++++++++++++++++++++++++++++++++++++++++++++++ + Joachim Breitner + + =================== + + ma...@jo... | ICQ # 74513189 + + Homepage: http://www.joachim-breitner.de/ + + 07032/24774 | Ehbühl 33 | 71083 Herrenberg + +++++++++++++++++++++++++++++++++++++++++++++++ + If anything can go wrong, it will. (Murphy) + +++++++++++++++++++++++++++++++++++++++++++++++ + Linux, because: + Open Minds. + + Software is like Sex - + Open Sources. + + It's better when it's free! + Open Future. + +++++++++++++++++++++++++++++++++++++++++++++++ + This message was written + + entirely with recycled electrons. + +++++++++++++++++++++++++++++++++++++++++++++++ + Crypt! Meine PGP-Key ID: C0395780 + +++++++++++++++++++++++++++++++++++++++++++++++ |
|
From: Josef R. <j.r...@ph...> - 2001-10-17 13:26:38
|
Joachim Breitner wrote: > > Hi all, > > it's been a bit silent here. anyway, what about this: > > We save some additional Info, e.g. into the filename (l234k5j2l34j234-gcc-3.0.1-kernel-2.4.10), so that after a compilerupdate (which is due to end of Oct, gcc-3.0.2), an simple perlscript can clean up the files from a specific compilerversion. > > So, why not just delete all files when the new compiler arrives? Would work for me, but some want to keep two compilers at one (e.g. gcc-3.0.x and gcc-2.x), which can be pretty useful, since not all progs compile with the new gcc. Or with networked or shared cache, you can't just delete all files, but you CAN perhaps delete a specific compiler version. > > Another example would be optimizer flags. When I sell my athlon and buy a whatever comes next, I have no use for cached athlon-optimized files. > > What do you think? why not saving into different directories for different compilers? yours josef |
|
From: Joachim B. <ma...@jo...> - 2001-10-17 11:38:25
|
Hi all, it's been a bit silent here. anyway, what about this: We save some additional Info, e.g. into the filename (l234k5j2l34j234-gcc-3.0.1-kernel-2.4.10), so that after a compilerupdate (which is due to end of Oct, gcc-3.0.2), an simple perlscript can clean up the files from a specific compilerversion. So, why not just delete all files when the new compiler arrives? Would work for me, but some want to keep two compilers at one (e.g. gcc-3.0.x and gcc-2.x), which can be pretty useful, since not all progs compile with the new gcc. Or with networked or shared cache, you can't just delete all files, but you CAN perhaps delete a specific compiler version. Another example would be optimizer flags. When I sell my athlon and buy a whatever comes next, I have no use for cached athlon-optimized files. What do you think? Joachim +++++++++++++++++++++++++++++++++++++++++++++++ + Joachim Breitner + + =================== + + ma...@jo... | ICQ # 74513189 + + Homepage: http://www.joachim-breitner.de/ + + 07032/24774 | Ehbühl 33 | 71083 Herrenberg + +++++++++++++++++++++++++++++++++++++++++++++++ + If anything can go wrong, it will. (Murphy) + +++++++++++++++++++++++++++++++++++++++++++++++ + Linux, because: + Open Minds. + + Software is like Sex - + Open Sources. + + It's better when it's free! + Open Future. + +++++++++++++++++++++++++++++++++++++++++++++++ + This message was written + + entirely with recycled electrons. + +++++++++++++++++++++++++++++++++++++++++++++++ + Crypt! Meine PGP-Key ID: C0395780 + +++++++++++++++++++++++++++++++++++++++++++++++ |
