共享库的版本控制

确定共享库的可用接口后，可以使用 mapfile 和链接编辑器的 -M 选项创建关联的版本定义。有关此 mapfile 语法的介绍，请参见定义其他符号。

以下示例定义了共享库 libfoo.so.1 中的供应商公共接口：

$ cat mapfile

SUNW_1.1 {                   # Release X.

        global:

                foo2;

                foo1;

        local:

                *;

};

$ cc -G -o libfoo.so.1 -h libfoo.so.1 -z text -M mapfile foo.c

全局符号 foo1 和 foo2 指定给共享库的公共接口 SUNW_1.1。输入文件中提供的任何其他全局符号均通过自动缩减指令 “*” 缩减到本地。 请参见缩减符号范围。

每个版本定义的 mapfile 项均应带有一个注释，用于反映更新的发行版或日期。可利用此信息将多个共享库更新整合（可能由不同的开发者进行）到一个版本定义中，从而使共享库的发布作为软件发行的一部分进行。

现有（非版本化）共享库的版本控制

对现有的非版本化共享库进行版本控制需要格外小心。上一个软件发行版中提供的共享库已使其所有全局符号可供其他目标文件绑定。尽管可以确定共享库的目标接口，但其他目标文件可能已发现其他符号并绑定到这些符号。因此，删除任何符号都可能会导致应用程序无法传送新的版本化共享库。

如果可以确定并应用接口，而不中断任何现有应用程序，则可以对现有的非版本化共享库进行内部版本控制。运行时链接程序的调试功能对验证各种应用程序的绑定要求非常有用。 请参见调试库。但是，确定现有绑定要求会假定共享库的所有用户都是已知的。

如果无法确定现有的非版本化共享库的绑定要求，则应使用新的版本化名称创建一个新的共享库文件。 请参见协调版本化文件名。除了这个新的共享库外，还必须传送原始共享库，以满足任何现有应用程序的依赖性。

如果要冻结原始共享库的实现，则只需维护和传送共享库二进制文件。但是，如果原始共享库需要更新，则更适合使用从中生成共享库的备用源树。修补程序升级可能需要更新，只有升级共享库的实现才能与新平台保持兼容时也可能要更新。