Question

我使用autoconf / automake / libtool来构建共享库。我想将主要数量的库版本传递给共享库soname。

我在configure.ac中有以下声明：

AC_INIT([libabc], [1.1.0])

以下Makefile.am：

AM_CPPFLAGS              = -I$(top_srcdir)/include -Wall -Wextra
LDADD                    = libabc.la

lib_LTLIBRARIES          = libabc.la
nodist_libabc_la_SOURCES = $(top_srcdir)/config.h
libabc_la_SOURCES        = $(top_srcdir)/src/abc.c

我可以为配置脚本，源和共享库soname提供相同的版本。我可以在源代码中使用自动生成的config.h中定义的VERSION或PACKAGE_VERSION，但这不会影响soname，它总是libabc.so.0。

有没有办法强制libtool使用AC_INIT指令中的主要版本？如果没有，定义主要/次要号码的首选方式是什么？

Answer 1

使用库进行版本控制非常复杂。 MAJOR.MINOR.MICRO版本控制系统可能适用于某些软件包，但有一些缺点。

MICRO修订版意味着该库具有内部更改 - 通常是错误修复 - 但对接口不透明。理想情况下，共享库应该是二进制兼容的。 MINOR修订版可能会添加功能，但不应破坏任何现有API。 MAJOR修订版可能会破坏API，需要更改应用程序代码。

libtool versioning system描述了一种更全面的方法，为current:revision:age描述提供了可以传递给libfoo_la_LDFLAGS -version-info的规则。还有另一种选择：libfoo_la_LDFLAGS = -release-info。该系统描述了兼容的库版本的“范围”。

我建议您查看使用'复杂'版本控制的成熟软件包的configure.ac和Makefile.am文件，例如GTK+, GLib库;并决定是否需要投资这种复杂性。

Ulrich Drepper有一些相当技术性的papers描述了最终的ABI版本。这些可能与系统libc（glibc）开发人员更相关，在这些关键库中维护符号版本信息，以及ELF ABI支持等。我将坚持查看维护良好的基础架构包，并提供良好的autotools支持。 ..

AC_INIT'版本'实际上是指维护者发布的软件包版本，与库版本控制无关。 MAJOR.MINOR.MICRO对于源代码分发来说并不是一个坏主意，因为它也描述了版本的时间顺序。

Answer 2

将其设置为零比分配每次更改的x.y.z版本更糟糕。虽然它不理想，x.y.z会阻止许多情况下的版本冲突。

使用-Wl,-soname,libXXX.so.1.0链接器参数。

Answer 3

来自https://phab.enlightenment.org/w/autotoolsintegration/

m4_define([v_maj], [1])
m4_define([v_min], [1])
m4_define([v_mic], [0])
m4_define([project_version], [v_maj.v_min.v_mic])

m4_define([lt_cur], [m4_eval([v_maj] + [v_min])])
m4_define([lt_rev], [v_mic])
m4_define([lt_age], [v_min])
version_info="lt_cur:lt_rev:lt_age"
AC_SUBST([version_info])

和src / lib / Makefile.am是：

MAINTAINERCLEANFILES = Makefile.in

include_HEADERS = Foo.h

lib_LTLIBRARIES = libfoo.la

libfoo_la_SOURCES  = foo1.c foo2.c
libfoo_la_LDFLAGS = -version-info @version_info@

如何在autoconf中定义共享库主要版本？

3 个答案: