Jeffrey Thorson wrote: > Is there an option to the compiler/linker that will produce a listing or > report of all modules included in the compiled program? > > What I mean by this is we have many programs that when compiled with our > own lib produce a completed compiled program. We need to know for each > stand alone program which lib modules are included in that program (We > have over 100 programs like this and would hate to have to do this by > hand). This in under a Linux environment. > > If there is not an option maybe a program that could extract that > information would work too. Part of the problem with your question is that this is very platform-specific. gcc supports a large number of extremely diverse environments and they all work differently. Plus gcc is just a compiler, it does not include the assembler, linker, or libc. This is a long-winded way of explaining why you probably weren't able to find anything remotely helpful in the gcc manual. Now, thankfully (and sadly on this list it's exceptional) you did state you were using linux so that means you're also probably using the GNU linker and GNU libc, which give you options for what you're trying to do. To get a list of shared libraries that your program links against is straightforward. You can run "readelf -d foo" or "objdump -p foo" and note the NEEDED tags, or you can run "ldd foo". This ldd command doesn't actually do any processing itself, it's just a shell script that sets some environment variables which are recognised by the dynamic loader (ld.so) which tells it to trace the loading of the program instead of actually loading it. You can achieve the same effect manually, e.g. "LD_TRACE_LOADED_OBJECTS=1 foo". Also note that there is a difference between looking at the NEEDED tags in the program header and having ld.so trace its loading. The former tells you just what the binary was directly linked against, the latter tells you the transitive closure of all libraries that would be loaded into memory when the program runs. For example if A links against libB and libB links against libC, then A might not have any direct source dependency on (or knowledge of) libC but nevertheless libC will still be required at runtime. For code/libraries that were statically linked it gets a little more complicated because there's no way to recover this information from the binary after linking has occured. For this you'll need to ask the linker explicitly to show you this information during linking. The linker has several options for this, such as -M to print a link map (or perhaps more usefully, -Map to output it to a file.) Note that in most cases the linker is called by the compiler, so you need to use -Wl to pass linker options. For example, if using autoconf style configure script, you could just set LDFLAGS="-Wl,-Map,filename.out" and then examine filename.out for the various objects and libraries that were included in the link. You'll probably need to post-process this with a script if you want a formatted list, but it's the only reliable way that I know of to determine what objects were statically linked into a binary. Brian
