Slowly compilation on RPi3 32bit mode

[axl]

I know they have to be the same version. But I recently ran into this issue. gcc-config was properly set on both systems. 6.3.0.

I don't remember which package I was compiling, but the makefile was generated to compile with a specific version of the gcc executable, like: armv6j-hardfloat-linux-gnueabi-gcc-6.3.0 and distccd wasn't aware that there was such an executable on the server. otherwise if you use armv6j-hardfloat-linux-gnueabi-gcc it will use the version of gcc that gcc-config points too.

I imagine all the links in /usr/lib/distcc/bin/ have their use. right? again. after you install or delete a version of gcc, it's a good idea to redo the links. especially if you have this many:

[NeddySeagoon]

axl,

I'm unable to test properly until the weekend. I only have a binary Gentoo until then.
My statement is based on switching compiler versions just with gcc-config and messing up by only switching the client (Raspberry Pi) end.

Like you, I use cross distcc too.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[axl]

I might have been wrong. I wanted to look those links up a bit more seriously but I just didn't have the time. Meanwhile though, I did figure out a scenario in which you have to recompile distcc.

Let's say you have a pi and a laptop like the original poster. For the sake of avoiding versions, let's say all work with version X. just X.

And you already had distcc compiled on laptop. Now, i'm not sure it enough to just compile crossdev gcc, and distccd is a go.

So let's say you dont need to recompile distcc when you add/delete another version of gcc. because gcc-config handles that. but, you do need to recompile it (or remake those links) at least when you add another arch to a distcc server.

Does that make sense?