After unmasking and emerging the beta gcc-config and eselect-compiler today, then updating the configuration manually (as documented on the amd64 list), to reflect amd64/x86 and (also Gentoo masked) gcc-4.0.1 and 3.4.4, I discovered eselect compiler list would list all the profiles, and say I changed them there, but emerge info stayed stuck on gcc-3.4.4, even when eselect said gcc-4.0.1. Running gcc --version from the command line confirmed 4.0.1 as well, but emerge info still says 3.4.4. Yes, that's after finishing the manual config update, running eselect compiler update, sourcing /etc/profile, and even exiting the shell and reentering it. I tried toggling the settings back to 3.4.4, then back to 4.0.1, as well. emerge info continues to insist I'm running 3.4.4 no matter what I try. Maybe the wrapper update didn't work? No error messages, and as I said, gcc --version is returning 4.0.1 as expected. If this is a known issue, if portage works but just doesn't /say/ the correct gcc, or if it hasn't been patched to detect the new settings method yet, I don't see it mentioned in either the amd64 list testing invite, or in the eselect-compiler doc readme. Further, no hint of any bugs mentioning it that I can find, either. Is there a quick way to see what portage is actually using, or is emerge info accurate? Reproducible: Always Steps to Reproduce: emerge info output, as well as the files from /etc/eselect/compiler/, to be attached.
Created attachment 70095 [details] selection.conf selection.conf as manually configured, then toggled via eselect compiler set.
Created attachment 70096 [details] the 3.4.4 conf, as manually configured
Created attachment 70097 [details] the 4.0.1 conf, as manually configured
Created attachment 70099 [details] emerge info output
Ok, thanks... this should be a small change to portage to do something like: if [[ -f ${ROOT}/usr/share/eselect/modules/compiler.eselect ]] ; then compiler=$(eselect compiler show) else compiler=<the old way of figuring it out> fi
anyway to detect this that doesn't rely on a path that (yes I'm being paranoid) may change down the line? assuming eselect is sane in it's exit codes, an eselect compiler show run + check for 250 exit code strikes me as a slightly better route.
Brian, how is it currently detecting it? Are you looking in gcc-config stuff or doing 'gcc --version'? 'gcc --version' seems like "the right way" to me, but the user reports that it doens't match what he gets when he manually does --version.
/etc/env.d/gcc/config detection, going by an earlier quick look in emerge- def getgccversion( is an easy target to grep for. If there is a better solution then the current trick, I'd definitely be interested. :)
(In reply to comment #8) > /etc/env.d/gcc/config detection... > emerge ... def getgccversion( > is an easy target to grep for. OK, taking a look at that code, it indeed is grabbing /etc/env.d/gcc/config, with a fallback to using the shell path with "gcc -dumpversion". Apparently the fallback can screw up distcc, however, as that's noted in the fallback warning. I take it that config pointer file was produced by the old gcc-config, but the new one uses the /etc/eselect/compiler/selection.conf file for the same thing, so the old one isn't updated? Anyway, renaming the env.d/gcc/config file to config.bak, so it's not found, produces the expected results: portage falls back to the shell method, with the warning about distcc. I don't use distcc, so that's fine, here, but I expect distcc folks will still have issues. So... I have my workaround, now, tho simply removing that file in the eselect-compiler ebuild will apparently cause issues for distcc folks. There's also the question of how portage might handle the non-default bitness stuff on amd64 and the like.
the distcc bit is kind of off, imo at this point. just cleanse the path so it's not including any distcc dirs, or look for gcc in a specific location (/usr/bin/gcc fex) should side step it... assuming users haven't done something "fun"
Sorry for not responding here... I've been insanely busy lately... Brian, what's wrong with just getting that info from: eselect compiler show or gcc-config -c or gcc --version
Adding Lisa to the cc, as metadata says she's distcc maintainer. Lisa, eselect-compiler-2.0 is looking to be unmasked, and portage 2.1-rc4 still has the following warning about distcc. Is it still valid? (The new location for the data is /etc/eselect/compiler/* or see comment *10 .) ~$emerge --info !!! Relying on the shell to locate gcc, this may break !!! DISTCC, installing gcc-config and setting your current gcc !!! profile will fix this Portage 2.1_rc4 (default-linux/amd64/2006.0, gcc-4.1.1, glibc-2.4-r3, 2.6.17-rc5 x86_64)
Ah, I haven't seen that error message before as I've still kept around /etc/env.d/gcc in case I needed to go back for something, but indeed this is a potential confusion spot. Is there really any reason to have that warning? AFAIK, that actually shouldn't cause distcc to break. Am I missing something?
Also as another note, the original bug reported here (incorrect gcc version reported in emerge --info) is fixed in portage 2.1
(In reply to comment #0) > After unmasking and emerging the beta gcc-config and eselect-compiler today, > then updating the configuration manually (as documented on the amd64 list) link? (In reply to comment #13) > Ah, I haven't seen that error message before as I've still kept around > /etc/env.d/gcc in case I needed to go back for something, but indeed this is a > potential confusion spot. > > Is there really any reason to have that warning? AFAIK, that actually > shouldn't cause distcc to break. Am I missing something? I'll migrate my local setup eselect-compiler and see if I can make portage play nice with it. I just need some docs...
(In reply to comment #12) > ~$emerge --info > !!! Relying on the shell to locate gcc, this may break > !!! DISTCC, installing gcc-config and setting your current gcc > !!! profile will fix this > Portage 2.1_rc4 (default-linux/amd64/2006.0, gcc-4.1.1, glibc-2.4-r3, > 2.6.17-rc5 x86_64) The message indicates that emerge was unable to determine you're currently selected compiler. Basically, we just to know the correct way for emerge to determine the compiler with the old gcc-config and the new gcc-config. If the new way and old way fail, then we will show a warning message.
Perhaps emrge should simply be using `gcc-config -c` to determine the compiler? Does that work with both the old and new versions?
[Given comment #17, you may have gotten past these, but for others, and for completeness...] (In reply to comment #15) > link? That link's rather dated. Here's a newer one (devel list): http://permalink.gmane.org/gmane.linux.gentoo.devel/38739 (In reply to comment #16) > (In reply to comment #12) > > !!! Relying on the shell to locate gcc, this may break > > !!! DISTCC > > The message indicates that emerge was unable to determine you're currently > selected compiler. Right. > Basically, we just to know the correct way for emerge to determine the > compiler with the old gcc-config and the new gcc-config. If the > new way and old way fail, then we will show a warning message. Not quite correct, as I have the new gcc-config merged and working, yet still get the error. You will I believe find that portage is only looking at the info from the old gcc-config, not from the new one. If the old info is missing, that message appears, regardless of the status of eselect-compiler and the new gcc-config wrapper around it. (RE: comment #14) Detecting the wrong version may be fixed in portage 2.1, but there's still something wrong, as I'm up2date with 2.1-rcs, eselect-compiler, and the gcc-config-2.0-rc wrapper around it, yet am getting the missing info warning, without the old gcc-config-1.x info there.
(In reply to comment #15) > > I'll migrate my local setup eselect-compiler and see if I can make portage play > nice with it. I just need some docs... Portage plays nice with it. It's been playing nice with it as long as I've been using it. I'm just confused why that warning is even there. As for docs, just see my recent post to gentoo-dev. (In reply to comment #16) > (In reply to comment #12) > > ~$emerge --info > > !!! Relying on the shell to locate gcc, this may break > > !!! DISTCC, installing gcc-config and setting your current gcc > > !!! profile will fix this > > Portage 2.1_rc4 (default-linux/amd64/2006.0, gcc-4.1.1, glibc-2.4-r3, > > 2.6.17-rc5 x86_64) > > The message indicates that emerge was unable to determine you're currently > selected compiler. Basically, we just to know the correct way for emerge to > determine the compiler with the old gcc-config and the new gcc-config. If the > new way and old way fail, then we will show a warning message. Actually, I don't think you do know the "correct" way for emerge to determine the compiler. It looks to me like you're looking directly in /etc/env.d/gcc since just removing /etc/env.d/gcc on my system causes this warning to appear. With gcc-config (both the old one and the new one which is just a wrapper to eselect-compiler), you can do 'gcc-config -c', and with eselect-compiler, you can do 'eselect compiler show'. Failing that, why don't you fall back on '${CHOST}-gcc -dumpversion' then 'gcc -dumpversion'?
(In reply to comment #19) > With gcc-config (both the old one and the new one which is just a wrapper to > eselect-compiler), you can do 'gcc-config -c', and with eselect-compiler, you > can do 'eselect compiler show'. Failing that, why don't you fall back on > '${CHOST}-gcc -dumpversion' then 'gcc -dumpversion'? Thanks. As you've suggested, I've fixed the logic in svn r3459 and it's been released in 2.1_rc4-r2.
Hey Zac, '-' appears after the / with multilib profiles, so for amd64, you'll get something like this: ~ # eselect compiler show x86_64-pc-linux-gnu-4.1.1/amd64-vanilla so emerge --info ends up showing: gcc-vanilla instead of: gcc-4.1.1/amd64-vanilla
Created attachment 88492 [details, diff] emerge.patch This fixes the problem for me. It also does the eselect first and falls back on gcc-config since the 'gcc-config -c' output might be from the old or new gcc-config and we need to handle them differently
Created attachment 88494 [details, diff] emerge.patch I addidently forgot to delete a '-' in that previous version... no difference in effect but better style.
Thanks again. This is in svn r3463 and has been released in 2.1_rc4-r3.
Please reopen if there are any more problems.
