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" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <distcc@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, [EMAIL PROTECTED] 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
__
distcc mailing list http://distcc.samba.org/
To unsubscribe or change options:
https://lists.samba.org/mailman/listinfo/distcc
