> I suspect the machines actually have different versions of gcc too. > This does not seem to be a distcc bug.
Yes, the gcc changes from gcc-3.2.3-53 => gcc-3.2.3-54 in RHEL3 U7. But such minor changes were made in previous RHEL3 updates as well. I had a feeling that updates for a particular version of OS(RHEL3 in my case) wouldnt disturb distcc. This affects the scope of using distcc. Raja On Tue, August 8, 2006 7:58 pm, Martin Pool wrote: > On 8 Aug 2006, [EMAIL PROTECTED] wrote: > >> Ya, i tried that..The symbol is still there.. >> >> >> # 50 "/usr/include/c++/3.2.3/i386-redhat-linux/bits/gthr-default.h" 3 >> ... >> extern __typeof(pthread_create) __gthrw_pthread_create __attribute__ >> ((__weakref__("pthread_create"))); >> ... >> "/usr/include/c++/3.2.3/i386-redhat-linux/bits/gthr-default.h" 3 >> static inline int __gthread_active_p (void) { static void *const >> __gthread_active_ptr = (void *) >> &__gthrw_pthread_create; return __gthread_active_ptr != 0; >> > >>> Yes, distcc runs cpp, which expands all #defines. It's pretty much >>> impossible that distcc could fail to run the precompiler. I'm not >>> sure how it could work locally and fail remotely. >> >> As i mentioned earlier, it will work for remote build if it is RHEL3 >> update 7 or higher(which has newer glibc). > > I don't have such a machine and can't debug this for you remotely. > > > I suspect the machines actually have different versions of gcc too. > This does not seem to be a distcc bug. > > > -- > Martin > > __ distcc mailing list http://distcc.samba.org/ To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/distcc