Which library contans the malloc object code and what is the name of the main library that C links to?

[Ray Hurst]

Brian Dessent wrote:
> Ray Hurst wrote:
> 
>> Thanks for the info. How do I display the contents of libc.a.
>> I tried ar -t libc.a and malloc did not show up.
>> However, if I open lib.c with a hex editor I can see that the symbol
>> __malloc exitst is libc.a
> 
> ar -t isn't ever going to give you useful information, as that only
> lists the filenames of object files in the archive.  It would be only by
> coincidence that a function was implemented in an object file by the
> same name.
> 
> For static archives you can use nm to list symbols, but this is like
> drinking from a firehose as it shows all references to all symbols from
> every object file, where you probably just want the 'T' ones, e.g.
> 
> nm -P libc.a | egrep "^[^ ]+ T" | sort -u
> 
> But since almost nothing is linked statically it would probably be
> better to look at the shared library.  For this you need to use objdump
> -T or readelf -s, and note that "libc.so" is not actually a shared
> object but a linker script, so you'll need to use the actual filename of
> the shared object, e.g. libc-x.y.z.so (or the symlink libc.so.x).  And
> also note that the shared version of the library uses symbol versioning,
> which allows one .so file to be backwards compatible with many other
> past versions, an essential requirement without which it would be very
> difficult to have binary distributions.
> 
> But more importantly, all of the above should be an absolute last
> resort.  glibc has great documentation that covers every function and
> interface, e.g.
> <http://www.gnu.org/software/libc/manual/html_node/Function-Index.html>. 
> This should be considered the definitive reference to how to use the
> library and what it provides, not hex dumps of library files and things
> like objdump.
> 
> Brian
> 
Thanks. This does the job.
Ray