[lug] (no subject)

[Dan Ferris]

Well, I've searched through most of the libraries on the system.  The 
only libraries that it finds those symbols in is libc.so.6 and the 
dynamic linker. ld-linux.so.

This is a very strange and frustrating problem.  I appreciate the help.

Dan

D. Stimits wrote:

>
>>> But more likely, two libraries are being mixed which were compiled 
>>> against the wrong versions. Simply put, some libraries reference 
>>> other libraries, and perhaps one was linked against the wrong 
>>> version...the end program is not the only code that can link against 
>>> libraries. If this is the case, then compiling from source (provided 
>>> you can find out what wants that symbol) would fix it.
>>
>>
>>
>>
>> I think this is more likely.  I'm going to reinstall gcc and glibc 
>> and the dynamic linker on a test box and see if that fixes the problem.
>
>
> Keep in mind that it isn't necessarily glibc/gcc which is linking 
> wrong. Since it is looking for "private" function symbols, chances are 
> it is...but someone could have done a "no no" in another library and 
> hooked into private functions of glibc (they are private because they 
> might change or go away without notice) from other libs. If the latter 
> is the case, then rebuilding glibc won't help, the other libs will 
> still be looking for the function signature that doesn't exist there 
> (and perhaps doesn't even exist at all anymore). If you know all 
> libraries involved, you can sometimes use nm to track down what 
> outside library is referencing it (combine with grep)...unfortunately 
> some libraries strip too much information to do this.
>
> D. Stimits, stimits AT comcast DOT net
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: lug.boulder.co.us port=6667 channel=#colug
>
>