[distcc] Problem between RHEL3 Update 7 and previous updates

[raja at ece.gatech.edu]

> 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, raja at ece.gatech.edu 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
>
>