LSB 2.0激活Linux世界新标准时代

LSB 2.0激活Linux世界新标准时代 2005.09.16
LSB 2.0的推出在整个Linux社区引起了广泛的关注。目前，非营利性组织开放系统开发实验室（OSDL）已宣布与FSG合作完成LSB 2.0的实验和推广工作，并有多家开放系统产品供应商表示支持LSB 2.0标准。
那么，LSB究竟是何方神圣？它对于开放系统的发展和推广将起到怎样的作用呢？
LSB标准的构成
LSB是一种应用程序二进制接口，主要解决Linux系统与应用程序之间的兼容问题。LSB是在IEEE POSIX源代码标准和Unix规范基础上建立起来的，包含多种接口技术。也有一些接口技术未被LSB收取，这些接口大多是开发接口或用户级工具。
LSB可以将源代码标准扩展至其它领域，例如图形领域等。此外，LSB还包括一些必要的技术细节，例如支持大型二进制应用软件平台的二进制执行文件格式等。LSB标准主要由以下两部分组成：
◆ 一个二进制接口标准和基础库；
◆ 应用程序实施的技术细节，包括软件打包格式、文件系统版面（主要是文件系统分级标准）和适用于应用程序的一些命令。
以LSB 1.3为例，其基础库主要包括以下两种：
◆ 基准库 libc、libm、libpthread、libpam、libutil、libdl、libcrypt、libncurses和libz。
◆ 图形库 libX11、libXt、libXext、libSM、libICE和libGL。
支持LSB标准的应用软件可产生一个二进制镜像，该镜像可通过一个特定的处理器架构运行于所有支持LSB标准的Linux系统中。此外，LSB标准还包括一些LSB认证的测试工具组件，如测试套件、用于应用软件LSB标准测试的Linux示范版，以及一组用来测试系统的应用软件。
LSB 2.0对核心的规范说明书做出修订，以支持建立在核心LSB基础上的模块。它将应用于日后发展，并随着Linux标准运用到不同的市场而添加新的特性，这些特性将作为核心LSB的扩展部分。
LSB 2.0很重要的一个新功能是可导入C++应用程序二进制接口（ABI）。这一功能可以提高代码互操作性，使多数软件供应商将应用软件以低廉的成本移植到Linux系统中。
LSB 2.0的改进还包括支持新的结构，如PPC64和AMD64。LSB支持的其它CPU结构还有IA32、IA64、PPC32、S/390和S/390X。
LSB标准的作用
时至今日，应用软件开发所需的成本已远远超过硬件成本。随着应用软件研发费用的增加和硬件成本的降低，为了能在有限的成本范围内量体裁衣，开发出功能强大且适合自身的应用软件，大多数企业开始把目光投向开放系统领域。
然而，开放系统用户们却都面临一个十分棘手的问题，那就是应用软件的可移植性。如何在不改变源代码的前提下，将某一应用程序或其中的一部分源代码移植到另一平台，并重新构建新的应用程序。
软件的可移植性问题不仅困扰着企业用户，也限制了硬件厂商的市场空间。软件厂商常常会列出其产品可兼容的系统清单，对多系统的支持将大大增加产品的研发成本。同时，用户也不得不为自己的应用程序选择可用的硬件产品。
所以，三方在兼容性问题上形成了一种博弈局面。
虽然，开放系统支持源代码移植，但这并没有带来真正意义的兼容，而二进制的可移植性却是打开这扇大门的钥匙。LSB标准就是一种确保各Linux版本与Linux应用软件兼容的业内标准。它的作用正如FSG官员所说的，是“开发并推广一系列可增加兼容性的业内标准”，而实现这一目标的关键在于二进制接口的开发。
FSG董事会成员Dirk Hohndel预测，尽管LSB不会建立一种单一的Linux操作系统，但它将提供一个环境，在这个环境中，支持LSB标准的各种Linux系统可以相互竞争，用户可以在所有Linux系统中使用这些支持LSB标准的应用软件。
LSB标准测试
尽管用户也会从LSB标准获得利益，但FSG的主要服务对象却是独立软件提供商（ISV）、Linux系统开发商和其它系统提供商，因为他们是开放系统发展壮大的中坚力量。目前，所有主要Linux系统提供商都已支持LSB标准，LSB标准检测已成为这些厂商的质检项目之一。
截至今年7月，已有11家厂商的35种产品注册获得LSB标准认证。但是，这些产品中却没有独立软件提供商的应用软件。如何才能获得LSB标准认证呢？对于Linux系统的测试与对ISV应用软件的测试十分相似，但也存在不同之处。
针对Linux系统的测试步骤
为了增加LSB标准的权威性和可信度，FSG专门推出了“LSB认证”产业标准及一系列测试项目。只有通过所有测试的系统和应用软件才能获得LSB认证证书。总的来看，针对Linux系统的测试主要有以下四个步骤：
1．了解认证程序和步骤；
2．对系统进行非正式测试；
3．申请进行认证测试；
4．进行正式测试并提交测试结果。
参加测试的Linux系统提供商必须了解LSB测试的过程，即系统提供商必须保证自己的产品通过所有的兼容性测试，签署商标认证协议并提交FSG。成功通过所有测试的Linux系统名称将列入FSG网页的认证登记表，向全世界公开。
参加测试的Linux系统通过非正式测试后，产品提供商要提供一份报告，报告中包括系统提供商的名称、产品名称和版本信息、用来测试系统的套件名称和版本，以及提供商对产品重新定义商标的态度。
申请认证的系统提供商必须在网上填写一份登记表。系统提供商必须选择一种LSB产品标准。针对Linux系统的产品标准包括支持IA32、IA64、32位PowerPC、64位PowerPC、S/390、S/390X和64位AMD等技术的LSB 2.0运行环境。
正式测试由系统提供商自己进行。完成后需将结果提交给认证授权机构审查，提交的结果必须包括在不间断进行所有测试情况下的全部系统运行日志。对于Linux系统来说，这些测试包括LSB运行时间环境测试和LSB国际化环境测试。通过所有测试并完成一系列提交程序后，系统提供商可以获得其产品的LSB认证，提交的相关信息也会在FSG网站上公布。值得注意的是，LSB认证只在规定的时间内有效。
针对ISV应用软件的测试步骤
针对应用软件的测试步骤与Linux系统的测试步骤大同小异。首先，二者所选择的测试套件不同；其次，选择的产品标准也不同，应用软件选择的产品标准包括支持IA32、IA64、32位PowerPC、64位PowerPC、S/390、S/390X和64位AMD技术的LSB 2.0应用程序。
支持LSB标准的应用软件主要应具备以下要素：
1．支持LSB标准的应用软件只能使用运行环境提供的LSB接口；
2．应用软件必须经正确打包以确保不同Linux系统和应用软件的兼容性；
3．应用软件提供商必须证明该应用软件可以在LSB示范系统下运行正常；
4．应用软件必须在两种不同的LSB运行环境下运行正常；
5．应用软件和其它软件套件必须安装在正常的目录下；
6．所有支持LSB标准的软件套件名称必须以“lsb-”开头。
如何建立LSB应用程序
LSB为应用软件和运行环境指定了一个接口。目前，许多Linux套件已获得LSB认证，但却还没有获此认证的应用软件。下面就来了解一下如何建立可与LSB接口连接的应用软件。
LSB应用程序开发环境
很久以前，人们就意识到在开发阶段对源代码进行修改要比以后进行修改简单得多，也廉价得多。考虑到这一点，LSB项目建立了一个应用程序开发环境来帮助用户开发支持LSB标准的应用程序。
这一开发环境提供了一整套开发和打包工具。LSB将许多定义标准存储在一个数据库中。这个数据库可以确保所有开发工具和规范同步工作。
LSB软件包
用户可以从LSB网站上获得LSB开发环境，但用户还需要自行安装下列软件包：
◆ sbdev-base 包含域名（header）和库；
◆ lsbdev-cc 包含编译程序打包工具；
◆ lsbdev-chroot 包含交替chroot-based环境；
◆ lsbdev-c++ 包含1个静态libstdc++，可用来为LSB移植一些C++应用程序。
建立支持LSB标准的应用软件，第一步是对源代码进行编译，使其与LSB域名相一致。如果源代码未被编译，它很可能正在被LSB外部程序使用，用户需要特别注意此类源代码。LSB域名安装在/opt/lsbdev-base/include目录下。最迅速的测试方法是，将-I/opt/lsbdev-base/include置于GCC中，观察其显示结果。编译程序打包器会帮助用户完成此步骤及相关操作。
用户完成对源代码的编译后，进入下一步，将源代码连接起来，建立最终应用程序。通常这一步如下：
#gcc -o app1 obj1.o obj2.o -lfoo
LSB存根库存储在/opt/lsbdev-base/lib目录下，可以通过向编译程序传递－L选项对它们进行指定。存根库只有在对源代码进行连接时才能使用，而通常情况下，普通系统库在运行时使用。同样的，编译程序打包器会帮助完成这一步骤。
完成应用程序连接后，用户可以使用ldd命令查看共享库的使用情况。就这一点而言，所有共享库都应该被指定，并显示在LSB库状态栏中。
检查无误后，用户需要进一步使其静态连接。通常可以选择“-Wl，-Bstatic”和“-Wl，-Bdynamic”选项，来指定需要进行静态连接的共享库。这时，用户可能会发现这些都可由编译程序打包器来完成。
以应用程序xpdf为例说明这一过程。通常情况下应用程序xpdf显示如下：
#ldd /usr/bin/xpdf
libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4
libt1.so.1 => /usr/lib/libt1.so.1
libfreetype.so.6 => /usr/lib/libfreetype.so.6
libSM.so.6 => /usr/X11R6/lib/libSM.so.6
libICE.so.6 => /usr/X11R6/lib/libICE.so.6
libX11.so.6 => /usr/X11R6/lib/libX11.so.6
libpaper.so.1 => /usr/lib/libpaper.so.1
libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3
libm.so.6 => /lib/libm.so.6
libc.so.6 => /lib/libc.so.6
/lib/ld-linux.so.2 => /lib/ld-linux.so.2
支持LSB标准的应用程序xpdf显示如下：
#ldd /opt/lsb-xpdf/bin/xpdf
libSM.so.6 => /usr/X11R6/lib/libSM.so.6
libICE.so.6 => /usr/X11R6/lib/libICE.so.6
libX11.so.6 => /usr/X11R6/lib/libX11.so.6
libm.so.6 => /lib/libm.so.6
libgcc_s.so.1 => /lib/libgcc_s.so.1
libc.so.6 => /lib/libc.so.6
/lib/ld-lsb.so.1 => /lib/ld-lsb.so.1
可以看到，应用程序需要的非LSB共享库并没有显示出来，原因是它们已静态地连接到应用程序自身。这里存在着一种平衡关系，随着应用程序的可执行性不断增强，它对操作系统的依赖性就越弱。
最后，来了解一下编译程序打包器、lsbcc和lsbc++。它们都是同一种程序，在C或C++模式下，对它们进行调用要使用不同的名称。一般来说，用户可以在使用GCC的地方使用lsbcc，在使用C++的地方使用lsbc++。
打包器可以将所有传递来的选项进行分类，并对其进行粗略地再处理。它可插入一些额外选项，使LSB提供的域名和库在其它普通系统库之前被利用。打包器还可以识别非LSB标准库，并指引它们进行静态连接。
LSB开发环境的使用
LSB开发软件包安装完毕后，用户可使用简单的三步法对应用程序进行移植：
#CC=lsbcc ./configure
#make
#make install
由于使用lsbcc代替了GCC，用户可以在LSB开发环境中进行各种测试，并且可以按照需要对软件进行设置。使用lsbcc的另一优势是它可以自动将CC分配到lsbcc，因此用户不需要在每次运行make时先执行“make CC=lsbcc”。lsbcc命令可以通过修改参数默认调用GCC，而且可以使用一个环境变量告知它使用何种替代编译程序。
测试工具
应用程序开发完成后，我们可以使用lsbappchk软件对程序进行测试，检验其是否支持LSB标准。lsbappchk软件可以检查应用程序使用的共享库列表，还可以检测用户是否使用不支持LSB标准的接口。使用方法如下：
#/opt/lsbappchk/bin/lsbappchk
/bin/ls/opt/lsbappchk/bin/lsbappchk
for LSB Specification 1.3.3
Checking binary /bin/ls
Incorrect program interpreter: /lib/ld-linux.so.2
Header[1] PT_INTERP  Failed
Found wrong interpreter in .interp section: /lib/ld-linux.so.2
instead of: /lib/ld-lsb.so.1
DT_NEEDED: librt.so.1 is used, but not part of the LSB
Symbol clock_gettime used, but not part of LSB
操作系统提供的工具软件并不需要符合LSB标准，因此用户不用强求操作系统的/bin/ls程序能通过这个测试。
lsbappchk软件的执行结果显示，/bin/ls并不是一个支持LSB标准的应用程序。首先，它无法与LSB定义的程序注释器/lib/ld-lsb.so.1连接起来；其次，该应用程序需要的共享库librt.so.1并不包含在LSB定义的库中；最后，clock_gettime()函数虽然被调用，但却无法静态连接至应用程序。
要想使此类应用程序支持LSB标准，需要使用lsbcc对应用程序进行重建。lsbcc可以正确设置程序注释器，使用librt.a代替librt.so。有时静态连接到某一库可以导致应用程序产生新的非LSB标准符号，因此需要经常重复这一过程。
对于一些大型应用程序或一组相关应用程序来说，用户需要建立一些只供此类应用程序使用的共享库。用户可以使用lsbappchk程序的-L选项将共享库的路径指引给测试工具，共享库可以作为应用程序的一部分参与LSB标准测试。
以下是对Apache Web服务器的LSB标准测试过程使用了3个专用共享库的结果：
#/opt/lsbappchk/bin/lsbappchk
-L /opt/lsb-apache/lib/libaprutil.so.0
-L /opt/lsb-apache/lib/libexpat.so.0
-L /opt/lsb-apache/lib/libapr.so.0
/opt/lsb-apache/sbin/httpd
/opt/lsbappchk/bin/lsbappchk for LSB Specification 1.3.3
Adding symbols for library /opt/lsb-apache/lib/libaprutil.so.0
Adding symbols for library /opt/lsb-apache/lib/libexpat.so.0
Adding symbols for library /opt/lsb-apache/lib/libapr.so.0
Checking binary /opt/lsb-apache/sbin/httpd
应用程序打包
LSB标准指定所有的程序包需以RPM格式递交。这并不意味着必须使用RPM来建立或打包应用程序，还可以使用Debian格式打包应用程序，然后再使用格式转换工具将其转换成RPM格式。
首先建立一个应用软件，并将其安装在一个临时目录下，然后调用RPM将其打包。这种方法也许有些笨拙，但却十分可靠。例如，为xpaint应用程序指定文件的过程如下：
Summary: An X Window System paint program
Summary: XPaint
Name: lsb-xpaint
Version: 2.6.2
Release: 3
Vendor: Free Standards Group
License: MIT
Group: Appbat/graphics
Buildroot: /usr/src/appbat/pkgroot/lsb-xpaint
AutoReqProv: no
PreReq: lsb >= 1.3
%description
LSB conforming version of xpaint.
XPaint is an X Window System color
image editing program and painting
program. Xpaint is added to the LSB
Application Battery primarily to demonstrate
the use of X11 libraries.
%pre
%install
%post
%preun
%postun
%clean
%files
%attr ( - bin bin ) /opt/lsb-xpaint
从LSB Project CVS树上可以找到应用程序建立及打包的全部源代码。
LSB标准的意义及发展前景
一个标准的应用软件二进制接口对于Linux系统有着非凡的意义，概括起来主要包括增强用户对应用软件的信心、降低成本和扩大市场。
应用软件得以迅速推广的原因主要在于用户对它的信心和支持。这种信心来自多个方面，包括兼容性、可移植性及可靠性。
首先，所有软件用户都希望自己使用的软件可以与其它软件兼容。
其次，用户需要软件有最大的可移植性，他们经常需要在不同的操作系统或架构上运行同样的应用软件，而不希望在不同系统上运行不同的软件版本。
再次，软件的可靠性也是用户选择产品时考虑的重要因素，因为这些应用软件可能担负着重要任务，可能服务于银行转账系统，也可能服务于医院信息系统。
LSB标准认证可确保应用软件满足客户的兼容性、可移植性和可靠性需求。因为，LSB使用户使用的软件更加标准化，确保它们与各种Linux系统的兼容。用户在所有支持LSB标准的架构下使用Linux系统，移植各种应用软件。LSB严格的测试程序确保支持LSB标准的应用软件有着较高的可靠性。
此外，对LSB标准的支持将大大降低厂商的开发成本及用户的使用成本。依靠一个基准应用程序接口，开发商在开发新软件时不需要再开发新的源代码。由于标准统一，软件开发商只要在一个系统中对产品进行测试就可“放之四海而皆准”。用户不需要在更换系统时再购买其它版本的应用软件。
随着用户对支持LSB标准的应用软件信心增强，以及开发和使用成本的降低，市场的扩大成为一种必然趋势。然而，LSB标准尚面临着技术上和体制上的双重挑战，开放系统提供商都不希望Linux社区四分五裂，同时又想保持自身的特色技术，以便在激烈的竞争中立于不败之地。未来，FSG将继续为LSB标准增加新的库，提高其稳定性和可扩展性。对于LSB开发环境来说，FSG将继续对开发工具进行完善，使其变得更加透明、更加简便。