[distcc] Problem between RHEL3 Update 7 and previous updates

Rajaprabhu Loganathan raja at cc.gatech.edu
Mon Aug 7 08:33:13 GMT 2006


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.


Raja


----- Original Message ----- 
From: "Martin Pool" <mbp at canonical.com>
To: <raja at ece.gatech.edu>
Cc: <distcc at lists.samba.org>
Sent: Sunday, August 06, 2006 8:16 PM
Subject: Re: [distcc] Problem between RHEL3 Update 7 and previous updates


> On  2 Aug 2006, raja at ece.gatech.edu wrote:
>> Hi,
>>
>> When i use distcc with one machine having RHEL3 update 7 and another one
>> having older update of RHEL3, we are getting the following error when we
>> do a dlopen on the generated library file.
>>
>> undefined symbol:   __gthrw_pthread_create(unsigned long*,
>> __pthread_attr_s const*, void* (*)(void*), void*)'
>>
>> We dont have this problem, when the distcc federation have machines with
>> only RHEL update 7.
>>
>> This is because, RHEL3 update 7 moved from
>> glibc-2.3.2-95.37 => glibc-2.3.2-95.39
>>
>> There is  "#define __gthrw_pthread_create ..." (gthr-posix.h) in
>> glibc-2.3.2-95.39 which is present in RHEL3 update 7.
>>
>> Since distcc does all preprocessing in the local machine, i was wondering
>> how this could create a problem.
>
> A change in only the headers and library should, as you say, be
> localized only to the client machine.  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.
>
> Is it really just that single package change that causes or solves the
> problem?
>
> -- 
> Martin
>



More information about the distcc mailing list