When linking a program with gcc on Linux or OSX how can I figure out how it's called when using -l

The name of the file which contains the lib and the nam开发者_JAVA技巧e used in -l do not always match. So how can I figure out the name used when linking? Usually I googled, but it should be somewhere in the system I think..

---

My answer's a bit messy, sorry about that. I'm pretty sure there's a better solution but this should help nevertheless.

During link-time, AFAIK the linker searches all library paths it knows about and looks for the arch-dependent library name, on Linux "-l foo" would search for "libfoo.so", on a Mac "libfoo.dylib". Now if you look for example in /usr/lib, you'll notice that there are a lot of symlinks. For example, if you have libfoo.so.1.2.3 there should also be symlinks libfoo.so.1.2 -> libfoo.so.1.2.3, libfoo.so.1 -> libfoo.so.1.2 and libfoo.so -> libfoo.so.1. The idea behind this is to support various versions. So if you need to know which file is used I suggest you do this:

Add "-v" to your LDFLAGS or directly to your call to gcc. This will result in a noisy output of gcc, the interesting thing is the call to "collect2". It has various arguments -L... and these are the directories the linker searches for libraries. You will also see -l... (lower case ell). You need to look into the -L directories for libraries given in -l and follow their symlinks.

If you need to know which library is used during runtime: that's a lot easier. Just run ldd some_program, it will tell you which libraries are used. It actually calls the program so that the dynamic linker kicks in, but passes an environment variable that makes the linker print out what it has loaded and exit the program before even starting it. On a Mac, use otool -L some_program.

For a running program, you need to find out the program's PID. Then do cat /proc/pid_of_program/maps. That gives you the memory map. The interesting part is the right hand column which lists the loaded libraries (because they get mmap'ed into the process). I don't know the equivalent for that on a Mac.

---

The best way to see what is happening here is to examine exactly what files gcc (both the compiler and the linker) is manipulating:

strace -f -e trace=open -o strace_output (your_gcc_command)

The '-f' is needed to follow child processes since that is how gcc works. I find this method to be extremely useful, since I can figure out exactly what libraries the linker is concatenating into my executable. I only wish that 'gcc -v' were this verbose.

---

Just type man gcc at a prompt to get the manual page for gcc. It details what the -l option does. If gcc is using ld as the linker then just do man ld for slightly more information. For example on my Linux system the latter says

-lnamespec
--library=namespec

Add the archive or object file specified by namespec to the list of files to link. This option may be used any number of times. If namespec is of the form :filename, ld will search the library path for a file called filename, otherise it will search the library path for a file called libnamespec.a.

On systems which support shared libraries, ld may also search for files other than libnamespec.a. Specifically, on ELF and SunOS systems, ld will search a directory for a library called libnamespec.so before searching for one called libnamespec.a. (By convention, a ".so" extension indicates a shared library.) Note that this behavior does not apply to :filename, which always specifies a file called filename.

Copyright (c) 1991, 92, 93, 94, 95, 96, 97, 98, 99, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 Free Software Foundation, Inc.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts.

Also note that on OSX if you set the environment variables RC_TRACE_ARCHIVES and RC_TRACE_DYLIBS then ld will print lots of useful debugging information. This can be helpful if you are picking up the wrong library at build time.