This is something I have noted that might save some people troubles, It might be worthwhile adding to the FAQ (I have just checked it isn't already there), or it might be self-evident and my own lack of knowledge is the problem.
I recently upgraded my cluster to gcc-4.1.0, binutils-2.16.91.0.7 and glibc-2.4. Three machines all running the same versions, built with the same configure switches and dependencies. The problem lies in that one machine hadn't rebuilt gcc against glibc-2.4 so it's specs for -fstack-protector included -lssp -lssp_nonshared ( the gcc ssp implementation) while the other two machines didn't (because glibc-2.4 has it's own ssp implementation). On a machine with a rebuilt gcc (where -fstack-protector doesn't have any associations in gcc's specs), at linking time failures kept occuring because of _stack_check_guard not being available in a stripped glibc (apparently glibc-2.4 has ssp information in the DWARF sections of ld.so libc.so.6 and libc*.a so stripping removed them). Explicitly adding -lssp -lssp_nonshared to the make rules fixed the problem, due to the shared objects compiled on the native gcc ssp system requiring that symbol. Like I said, I don't know if it is because of my own build system being unorthodox (stripped glibc) or if it is worthy of adding to the FAQ to avoid anyone else's problems. Hamish Greig __ distcc mailing list http://distcc.samba.org/ To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/distcc
