- -A 显示对象文件名称
- -C 显示程序中的原始名称
- -D 打印动态负号
- -u 打印那些未定义的符号
查看elf文件一脸的 so 动态链接库
–undefined symbols =
Do not report any unresolved symbols.
Report all unresolved symbols. This is the default.
Report unresolved symbols that are contained in shared libraries, but ignore them if they come from regular object files.
Report unresolved symbols that come from regular object files, but ignore them if they come from shared libraries. This can be useful when creating a dynamic binary and it is known that all the shared libraries that it should be referencing are included on the linker's command line.
Report unresolved symbol references from regular object files. This is done even if the linker is creating a non-symbolic shared library. The switch --[no-]allow-shlib-undefined controls the behaviour for reporting unresolved references found in shared libraries being linked in.
Allows or disallows undefined symbols in shared libraries. This switch is similar to --no-undefined except that it determines the behaviour when the undefined symbols are in a shared library rather than a regular object file. It does not affect how undefined symbols in regular object files are handled. The default behaviour is to report errors for any undefined symbols referenced in shared libraries if the linker is being used to create an executable, but to allow them if the linker is being used to create a shared library. The reasons for allowing undefined symbol references in shared libraries specified at link time are that: A shared library specified at link time may not be the same as the one that is available at load time, so the symbol might actually be resolvable at load time. There are some operating systems, eg BeOS and HPPA, where undefined symbols in shared libraries are normal. The BeOS kernel for example patches shared libraries at load time to select whichever function is most appropriate for the current architecture. This is used, for example, to dynamically select an appropriate memset function.