understanding userspace includes

[Deron Meranda]

On Sun, 27 Feb 2005 13:49:59 -0800, cfk <cfk at pacbell.net> wrote:
> However, when I try what should be a simpler case, that of string.h, I cannot
> find a string.o in libc.so. 

A *.so file is a shared object (also called a shared library).  Think of it as
a compiled version of a *.a archive file.  Whereas the *.a is just a container
for the individual *.o object files, the *.so is a single object file which is
the result of linking all of the original *.o files together.

Now, you *could* find a string.o inside libc.a, but you won't.  What
you will find is a whole bunch of different object files which together
provide everything mentioned in the header file string.h, such as
strcat.o
strchrnul.o
strchr.o
strcmp.o
strcoll_l.o
strcoll.o
strcpy_chk.o
strcpy.o
strcspn.o
strdup.o
...and so on...

> I would appreciate a bit more tutelage on going from an arbitrary include file
> in /usr/include and figuring out how to then find the shared object library
> that includes the executable for a particular header include file.

Unfortunately I know of no easy way.  I've been doing this for years on
many different Unix versions; and at least Linux in my opinion is a bit
easier to navigate, but there's still no formula.

Sometimes the header file itself will give you a clue,

   # rpm -qf /usr/include/string.h
   glibc-headers-2.3.4-2.fc3

which then leads you to glibc.  And then you can find potential libraries
with something like,

   # rpm -ql glibc | grep lib/lib

For glibc in particular there will be a ton of libraries, but for most packages
you'll only be dealing with a couple or so.


Without the use of RPM, which makes this a lot easier, you're down to
trying nm, say looking for a particular function or symbol.  You may find
these options most useful

  # nm -A -g --defined-only /usr/lib/libc.a | grep strcpy

Don't forget to read the manual pages too.  Sometimes they will
contain information about libraries, etc.

And if you're going to be trying to navigate through all the header files,
it will be worth your while to read /usr/include/features.h.  Also you'll
notice that many headers do nothing but include other headers under
the sys subdirectory, so that /usr/include/XXX.h includes the header
/usr/include/sys/XXX.h.

Also most constants (numbers, etc.) are defined in headers under the
"bits" subdirectory.  And you will probably be in /usr/include/bits/types.h
a lot too.

Good luck, it can take a lot of investigative work.  But as I said,
Linux is much more sane than most commercial Unices, so it
could be worse.

-- 
Deron Meranda