The distcc server started by /etc/init.d/distccd doesn't pick up compiler changes made by gcc-config, so it needs to be restarted after such a change. If you don't want to check if the service is running and restart it, at least show a message.
>=sys-devel/gcc-config-2.0 should not require restart: https://gitweb.gentoo.org/proj/gcc-config.git/commit/?id=9b907ef80bc421df23515afc4c306e4d96c67649 Can you try that if you have a way to reproduce it? Make sure you sourced '/etc/profile' before starting /etc/init.d/distccd as it might leak your current PATH into it.
What you linked might be the actual source of the problem. I use distcc-3.2_rc1-r5 with gcc-config-2.0 and, from what I gather, distcc dereferences symbolic links when the daemon starts. That's why changing that symlink later on has no effect on the compiler used by the distcc server.
That's unfortunate. But from how I read 'dcc_check_compiler_masq()' it does not resolve a link farther than one level off distcc's masquerade directory at least when it check the compiler itself: https://github.com/distcc/distcc/blob/master/src/serve.c#L342 There is quite a bit more of code that does it. What does distcc print when it breaks for you?
It doesn't break. I uses the previously selected compiler version instead of the new one. I caught this while trying to compile some code using PGO on a distcc client (profiling doesn't work, of course) and seeing a "version mismatch" warning message during the profiling run, because the compilation that was done remotely used a different version of the compiler compared with the linking done locally. Since I was sure that both systems had the same exact GCC version selected with gcc-config, I looked into what version the distcc server was actually using and that's how I found it decides that at service start time.
I failed to find any caching logic in distcc. I would like to make sure you did not have PATH with absolute path to gcc prepended neither on client side nor on server side. Those are hard to get rid of in '<gcc-config-2' world. Can you post your 'emerge --info' on client and on server? I'll also try to reproduce locally.
> I failed to find any caching logic in distcc. Same here, but I did find the culprit in the init.d script: 'eval "$(gcc-config -E)"'. That prepends something like "/usr/x86_64-pc-linux-gnu/gcc-bin/8.2.0" to PATH, where "8.2.0" is the selected GCC version at the time the service was started. That's why switching to another version without restarting distccd has no effect. > I would like to make sure you did not have PATH with absolute path to gcc prepended neither on client side nor on server side. :-) > I'll also try to reproduce locally. Here's how to reproduce it: - on the client, create a simple test.c (a main() with a "return" in it is fine); run "distcc gcc -O3 -c test.c -o test.o && strings test.o | grep GCC" - on the server enable another GCC version with gcc-config - re-run the compilation on the client - you'll see the old compiler's string - restart distccd on the server - re-run the compilation on the client to see the new compiler string Let me know if you still need my emerge --info. Commenting out 'eval "$(gcc-config -E)"' from /etc/init.d/distccd fixes my problem, but it's worth revising this old issue for a better solution: https://bugs.gentoo.org/262773 This, for example, looks promising, but the versioned GCC paths need to be appended, not prepended (in order to not mess with the search for "gcc"): https://262773.bugs.gentoo.org/attachment.cgi?id=185285
(In reply to Ștefan Talpalaru from comment #6) > > I failed to find any caching logic in distcc. > > Same here, but I did find the culprit in the init.d script: 'eval > "$(gcc-config -E)"'. > > That prepends something like "/usr/x86_64-pc-linux-gnu/gcc-bin/8.2.0" to > PATH, where "8.2.0" is the selected GCC version at the time the service was > started. > > That's why switching to another version without restarting distccd has no > effect. Woohoo! Great debugging! So distcc was subtly broken ever since. Just dropping 'eval "$(gcc-config -E)"' should be no worse than current state. Reassigning to cluster@ as current maintainer to sort this out. toolchain@ can also offer co-maintenance of distcc (we do ccache).
distcc-3.3 in Gentoo will not embed paths anymore: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ffd45776bb13d8ee7140fd5499413a7ffa873798 That should make 'gcc-config' to take instant effect.
