linux编译动态库未定义,linux 编译动态链接库 so，避免运行时才发现函数未 ......

ldd  查看 elf文件依赖的  so 动态链接库

可以  export

LD_LIBRARY_PATH=/path 设置 so文件的路径，

nm  -u  *.so  或者 nm

|grep  U 查看

那些在  动态链接库中的符号。

"U" The symbol is undefinedundefined的 symbol

这种就是表示 在其他 so动态链接库里面定义的。但是如果你的编译的

是so文件，如果符号不在外部任何so文件里面，默认的配置也不会提示错误。而是编译通过。那个自己忘了定义的符号也在 这

undefined

symbol里面，但是运行时就加载不成功了。

文档说，这种编译so动态链接库时找不到符号(不在任何外部so文件里面，自己的程序也没有定义)也允许编译通过是有原因的，参见

ld 的man 说明  --allow-shlib-un

更多来源：http://www.zgjx114.com

defined 解释(好像英文版的才完整，中文的man ld不完整 可以直接查看网页

https://sourceware.org/binutils/docs-2.24/ld/Options.html#Options

)。就是让你链接时用的一个版本的so，运行时加载用的另外一个版本的so，可能你的加载时的so里面有这个符号，所以就先让你找不到符号也编译通过了。如果是编译exe，这中链接时找不到定义的符号的就直接给你报错了。

so动态链接库就不会报错。其实这种特性应该是比较少用，最好在so链接是碰到这个未找到的符号也是报错的好。

所以我觉得编译的动态链接库的时候最好加上

--unresolved-symbols=ignore-in-shared-libs  或者

--no-undefined 来检查一下。这样如果是自己的疏忽在 .c 源文件里面忘记的

某函数的定义，，编译的时候就可以提示错误了。

这里有3个参数可以使用--undefined symbols

和 --no-allow-shlib-undefined

参数的作用范围不一样而已，--undefined symbols

针对常规object文件，--no-allow-shlib-undefined针对的是符号在外部的未定义的shared

object里面。--unresolved-symbols和--undefined symbols

作用差不多，不过更具体一些。

我们的目的主要是编译一个so动态链接库时，把自己object里面未定义的符号report出来就可以了，用--no-undefined和--unresolved-symbols=ignore-in-shared-libs应该可以的。

ld  的参数，  如果直接用gcc 编译，可以用

-Wl,--no-undefined 这样传过去

gcc -shared -Wl,-soname,libb.so.1,--no-undefined -o libb.so.1.2

objectfile

gcc -shared

-Wl,-soname,libb.so.1,--unresolved-symbols=ignore-in-shared-libs

-o libb.so.1.2  objectfile

---------------------------------------

--no-undefined-z defsReport 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.

----------------------------

--unresolved-symbols=method

Determine how to handle unresolved symbols. There are four

possible values for

`method':`ignore-all'Do not report

any unresolved symbols. `report-all'Report all unresolved symbols. This is

the default. `ignore-in-object-files'Report unresolved symbols

that are contained in shared libraries, but ignore them if they

come from regular object files. `ignore-in-shared-libs'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.

The behaviour for shared libraries on

their own can also be controlled by

the --[no-]allow-shlib-undefined option.

Normally the linker will generate an

error message for each reported unresolved symbol but the

option --warn-unresolved-symbols can

change this to a warning.

-----------------------------

-static

Do not link

against shared libraries.  This is only meaningful

on

platforms

for which shared libraries are supported.  The

different

variants of

this option are for compatibility with various systems.

You may use

this option multiple times on the command line: it

affects

library searching for -l options which follow it.

This

option also

implies --unresolved-symbols=report-all.  This

option

can be used

with -shared.  Doing so means that a shared

library is

being

created but that all of the library's external

references

must be

resolved by pulling in entries from static libraries.

--allow-shlib-undefined

--no-allow-shlib-undefinedAllows 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.