[lug] (no subject)
dan at usrsbin.com
Wed May 18 13:42:15 MDT 2005
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.
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
More information about the LUG