if i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -O2 -march=athlon-xp -pipe -MT env.o -MD -MP -MF ".deps/env.Tpo" -c -o env.o env.c; \ then mv -f ".deps/env.Tpo" ".deps/env.Po"; else rm -f ".deps/env.Tpo"; exit 1; fi if i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -O2 -march=athlon-xp -pipe -MT failure.o -MD -MP -MF ".deps/failure.Tpo" -c -o failure.o failure.c; \ then mv -f ".deps/failure.Tpo" ".deps/failure.Po"; else rm -f ".deps/failure.Tpo"; exit 1; fi In file included from ../lib/prototypes.h:27, from env.c:37: ../lib/defines.h:39:15: error: macro "strchr" requires 2 arguments, but only 1 given In file included from ../lib/prototypes.h:27, from env.c:37: ../lib/defines.h:39: error: 'strchr' redeclared as different kind of symbol make[2]: *** [env.o] Error 1 make[2]: *** Waiting for unfinished jobs.... failure.c: In function 'failure': failure.c:66: warning: incompatible implicit declaration of built-in function 'memset' failure.c:78: warning: incompatible implicit declaration of built-in function 'strncpy' make[2]: Leaving directory `/var/tmp/portage/shadow-4.0.15-r2/work/shadow-4.0.15/libmisc' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/shadow-4.0.15-r2/work/shadow-4.0.15' make: *** [all] Error 2
Created attachment 88173 [details] emerge --info
Disabling confcache fixed that, sorry.
Or rather not disabling but just flushing after upgrade to gcc-4.1.1. I think it will be good to add note about it to gcc upgrade guide.
How about something like this? --- toolchain.eclass.orig 2006-05-30 00:05:55.000000000 +0200 +++ toolchain.eclass 2006-06-02 13:38:11.000000000 +0200 @@ -2015,6 +2015,11 @@ ebeep return 1 fi + + if has confcache ${FEATURES} ; then + einfo "You should clear your confcache after upgrading gcc" + einfo "to avoid compile failures." + fi } do_gcc_config() {
that's also a good idea, but adding such info to gcc upgrade guide is imo essential, cause many people miss all that warnings displayed between merging new files and removing old ones during package upgrade.
(In reply to comment #4) > How about something like this? How much users will see this?! It's probably better always to clear the cache, when switching from one compiler to the other.
s/much/many/
(In reply to comment #6) > How much users will see this?! It's probably better always to clear the cache, > when switching from one compiler to the other. About as many users as any other einfo/ewarn... So, shall we drop all the messages b/c people don't read them? BTW, that's what ELOG in portage-2.1 is for. ;)
> About as many users as any other einfo/ewarn... So, shall we drop all the > messages b/c people don't read them? BTW, that's what ELOG in portage-2.1 is > for. ;) That's true for sure, it won't hurt anyone... but don't you think that gcc upgrade guide is a also a good place? ;]
(In reply to comment #8) > About as many users as any other einfo/ewarn... So, shall we drop all the > messages b/c people don't read them? BTW, that's what ELOG in portage-2.1 is > for. ;) Exactly. But it can be done automatically, so there's no reason to bug the user. Same goes for a lot of these ewarn's, if Portage had the required functionality.
Carsten Lohrke's last post remembered me that emerging a new gcc version is not equal to using it. It must be switched with gcc-config(in future with eselect) so i think that will be the best place to display such note. And imho doing it automatically is not the best resolution b/c it could be not wanted in some specific situations.
Hey docs guys, could someone add a note to the upgrading guide saying something about flushing the cache for confcache (and I'm assuming ccache as well) after you switch to your new compiler (not necessarily are you emerge it). I don't play with either of those ever, so I'm not sure what the options are or such. I'd rather add this to the upgrading guide than have even more einfo messages spamming users.
(In reply to comment #12) > (and I'm assuming ccache as well) According to the [1], ccache is not affected. [1] http://ccache.samba.org/ccache-man.html: "(generate the has of) the real compilers size and modification time"
ccache is not affected so that it would cause compile failures, its contents is just useless after upgrading gcc...
no, either confcache works or it doesnt ccache does the right thing already without any user intervention when switching between gcc versions
(In reply to comment #4) > How about something like this? > --- toolchain.eclass.orig 2006-05-30 00:05:55.000000000 +0200 > +++ toolchain.eclass 2006-06-02 13:38:11.000000000 +0200 > @@ -2015,6 +2015,11 @@ > ebeep > return 1 > fi > + > + if has confcache ${FEATURES} ; then > + einfo "You should clear your confcache after upgrading gcc" > + einfo "to avoid compile failures." > + fi > } > do_gcc_config() { if the route for the manual clearing of confcache is choosen instead of the automatic clearing then would you be so kind to add to this patch how users can do this as i have absolutely no idea how to clear the confcache. there is no man page for confcache, confcache --help doesn't give me a clue either, even the forums don't provide me a way to do this. Could someone who has a clue post the way to do it to this bug so i can enable confcache again and merge packages. thanks!!
> Could someone who has a clue post the way to do it to this bug so i can > enable confcache again and merge packages. thanks!! Just remove /var/tmp/confcache
(In reply to comment #17) > > Could someone who has a clue post the way to do it to this bug so i can > > enable confcache again and merge packages. thanks!! > Just remove /var/tmp/confcache thanks! removed /var/tmp/confcache, enabled confcache, emerge is working fine now.
(In reply to comment #11) > Carsten Lohrke's last post remembered me that emerging a new gcc version is not > equal to using it. It must be switched with gcc-config(in future with eselect) > so i think that will be the best place to display such note. There's no need to display anything. Just let gcc-config rm -rf /var/tmp/confcache, when a switch to a different gcc abi is requested and everything is fine.
no
Automagic is not what i like ;] In other words i don't think it would be always wanted behaviour. Or maybe it would be the best if confcache kept its cache in gcc-versioned folders, /var/tmp/confcache/4.1.1/ for example. Or some other trick ;] Maybe ferringb will figure out smth...
I'm closing them as UPSTREAM as for now I can't do much until Brian provides me a new version of confcache that allows to trace who poisoned the cache. This is also the main reason why confcache is masked right now.
