How to make gcc or ld report undefined symbols but not fail?

If you compile a shared library with GCC and pass the "-z defs" flag (which I think just gets passed blindly on to ld) then you get a nice report of what symbols are not defined, and ld fails (no .so file is created). On the other hand, if you don't specify "-z defs" or explicitly specify "-z nodefs" (the default), then a .so will be produced even if symbols are missing, but you get no report of what symbols were missing if any.

I'd like both! I want the .so to be created, but I'd also like any missing symbols to be reported. The only way I know of to do this so far is to run it twice, once with "-z defs" and once without. This means the potentially long linking stage is done twice though, which will make the compile/test cycle even worse.

In case you're wondering my ultimate goal -- when compiling a library, undefined symbols in a local object file indicates a dependency wasn't specified that should have been in my build environment, whereas if a symbol is missing in a library that you're linking against that's not an error (-l flags are only given for immediate dependencies, not dependencies of dependencies, under this system). I need the report for the part where it lists "referenced in file" so I can see whether the symbol was referenced by a local object or a library being linked. The --allow-shlib-undefined option almost fixes this but it doe开发者_如何转开发sn't work when linking against static libraries.

Preference to solutions that will work with both the GNU and Solaris linkers.

---

Instead of making ld report the undefined symbols during linking, you could use nm on the resulting .so file. For example:

nm --dynamic --undefined-only foo.so

EDIT: Though I guess that doesn't give you which source files the symbols are used in. Sorry I missed that part of your question.

You could still use nm for an approximate solution, along with grep:

for sym in `nm --dynamic --undefined-only foo.so |cut -d' ' -f11 |c++filt -p` ; do
    grep -o -e "\\<$sym\\>" *.cpp *.c *.h
done

This might have problems with local symbols of the same name, etc.

---

From the GNU ld 2.15 NEWS file:

• Improved linker's handling of unresolved symbols. The switch --unresolved-symbols= has been added to tell the linker when it should report them and the switch --warn-unresolved-symbols has been added to make reports be issued as warning messages rather than errors.