[distcc] Problem between RHEL3 Update 7 and previous updates

[raja at ece.gatech.edu]

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).

Raja



On Mon, August 7, 2006 4:16 am, Martin Pool wrote:
> On  7 Aug 2006, Rajaprabhu Loganathan <raja at cc.gatech.edu> wrote:
>
>> This problem has been noticed many packages not just one.
>>
>>
>>> Perhaps you actually just have an old object file around in your
>>> build directory? Sometimes compilers emit dependencies to different
>>> internal symbols when they're upgraded.
>>
>>
>> We have older glibc(glibc-2.3.2-95.37) in RHEL3 having updates older
>> than "Update 7".  Do you mean, that we should upgrade our "glibc" in all
>> the machines?
>>
>> Yes we have old libary files that we link to.  But if we dont use
>> distcc and just use gcc on the local machine, our builds work perfectly.
>> We dont have
>> any problem. The problem occurs only if we use 'distcc'.
>>
>> Also the undefined symbol is a "#define" statement.  Wont 'distcc'
>> substitute all "#defines" during preprocessing.  Moreover "#define
>> __gthrw_pthread_create    pthread_create"
>> It  "#define" the symbol "__gthrw_pthread_create" to "pthread_create"
>> which is present in older versions.
>
> 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.  Try looking at the preprocessor
> output (run gcc with -E) and see if the symbol is still there.
>
> --
> Martin
> __
> distcc mailing list            http://distcc.samba.org/ To unsubscribe or
> change options: https://lists.samba.org/mailman/listinfo/distcc
>
>