On 7 Aug 2006, Rajaprabhu Loganathan <[EMAIL PROTECTED]> 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
