On Sun, 27 Feb 2005 13:49:59 -0800, cfk <cfk@xxxxxxxxxxx> 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
