Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!samsung!noose.ecn.purdue.edu!orchestra.ecn.purdue.edu!songer
From: songer@orchestra.ecn.purdue.edu (Christopher M Songer)
Newsgroups: comp.unix.internals
Subject: Debugging library incompatibilty
Summary: How to...
Keywords: libc
Message-ID: <1991Jan9.201232.13435@noose.ecn.purdue.edu>
Date: 9 Jan 91 20:12:32 GMT
Sender: news@noose.ecn.purdue.edu (USENET news)
Followup-To: comp.unix.internals
Distribution: usa
Organization: Purdue University Engineering Computer Network
Lines: 17

Hi,
     Here is my problem (one of them anyway :) I have a library required
to interface with a graphics processor. The library is compiled for SUN3 
architecture.  I do not have access to the source. There is no maintanence 
agreement.  All I have is the library binary. It has not been stripped.
     A change was made to libc. (Involving the nameserver -- I did not
make the change.) All other programs have worked fine with the change.
How do I find the problem and (hopefully) fix it. I've used nm and gotten
a list of the system calls the library uses. What should I do now? How hard
is it to make a version of libc (without having root) with the -g option
on? Since libc is HUGE and spread out over so many files, if I have to
get the individual routines and compile them separately, is there an index
to what files are where in the tree? 
     I'm new to this particular sort of problem, so suggestions are more
than welcome. Thanks!

Chris		/* I work for and go to Purdue -- I don't speak for it */