centos lsb_开发经过LSB认证的应用程序

centos lsb

新闻快讯。 Linux已经超越了UNIX的源代码兼容性，迈出了下一步的发展步骤。 与其将源代码从一个Linux版本或发行版移植或重建到另一个Linux版本或发行版，Linux都实现了它们之间的二进制兼容性。 应用程序开发人员只需为每个Linux体系结构（例如IA-32，PowerPC或Itanium）构建一次，然后进行部署。

Linux本质上具有二进制兼容性。 但是，Linux标准库（LSB）设置了一些规则和准则，使其对于应用程序切实可行。 （请参阅相关信息的链接，LSB的主页。）的路径来收缩包装为Linux需要你的LSB的应用程序代码的可移植性层，使用正确的ABI，测试与LSB应用程序检查器，请LSB的包装指南，并寻求LSB认证。 本文介绍了使用LSB资源开发二进制兼容应用程序的五个基本步骤。

步骤1.编码到可移植层

诸如UNIX和Linux之类的开放系统没有让应用程序直接访问操作系统资源，而是具有将应用程序编码到的可移植层。 这是所有行为良好的应用程序都应写入的源代码兼容性层。 通常，此编码层是POSIX应用程序编程接口（API）的集合。 （请参阅相关信息的链接，在一个单一UNIX规范的开发的更多信息。）然而，因为我们知道“GNU不是UNIX”的LSB重新定义了POSIX在Linux，因此LSB规范标准。

有UNIX品牌的系统可确保UNIX系统之间的应用程序的源代码兼容性，而LSB品牌的系统可确保LINUX应用程序的二进制兼容性。 但是，在兼容性定义的范围内，必须对应用程序进行编码以使用API​​或应用程序二进制接口（ABI）。 应用程序不得使用操作系统的专用接口，也不能通过直接访问操作系统资源来破坏可移植性层。

平台调整的应用

直接访问系统资源的应用程序或中间件被称为“平台优化的”。 有时这样做是出于优化目的，但是它大大降低了软件在系统或发行版之间二进制兼容的可能性。 此类软件有时是平台品牌的，可以用于特定版本的操作系统，如果这样做的话，这很好。 但是，这种编程风格不在LSB的范围内。

符合LSB规范的应用很可能在LSB品牌的系统集之间是二进制兼容的。 通常，如果应用程序可以限制自己仅使用以下14个系统库，则它们就有可能成为LSB兼容的：libc，libdl，libm，libutil，libcrypt，libz，libpthread，libncurses，libX11，libXext，LibXt，libICE，libSM，和libGL。

如果应用程序无法将自身限制为上面列出的库的接口，则-为了最大程度地减少运行时错误-应用程序必须将未指定的库捆绑为应用程序的一部分，或者必须将库静态链接到应用程序。 但是，库本身必须仅通过使用上面列出的库的接口来符合LSB。

步骤2.使用正确的ABI

将开发限于源API规范不足以实现二进制兼容性，因为不同的发行版和不同的系统具有不同的库版本。 为了变得二进制兼容，您必须开发到ABI 。 与Solaris类似，Linux能够对单个ABI进行版本控制。 因此，如果虚函数kraft(x,y)当前返回一个double，但是ABI的最新版本返回一个整数，则必须使用指定的版本来返回原始的聚合数据类型。 为此，LSB已创建存根库。 您可以链接到LSB存根库和LSB运行时链接程序。 那么就可以单独使用LSB指定的ABI。 应用程序内部版本使用的不是LSB所指定的内容，或者应用程序内部版本会得到未解决的符号错误，或者LSB存根库将根据二进制规范确保正确的ABI。

为了简化具有正确ABI的应用程序的编译，LSB提供了一个lsbcc包装器脚本。 该lsbcc使用具有正确ABI的LSB存根库，LSB运行时链接程序（ld-lsb.so.1）和与LSB规范相对应的头文件。 您需要做的就是从LSB下载lsb-base和lsb-cc软件包（请参阅参考资料中的下载链接），然后将它们集成到您的常规构建过程中：

$ rpm -i ftp://ftp.freestandards.org/pub/lsb/lsbdev/lsbdev-base-1.2.2-1.i386.rpm
$ rpm -i ftp://ftp.freestandards.org/pub/lsb/lsbdev/lsbdev-cc-1.2.2-1.i386.rpm
$ lsbcc -o myapplication myapplication.c

要么

$ CC=lsbcc make myapplication

要么

$ CC=lsbcc ./configure; make myapplication

假设kraft是libc提供的ABI，并且版本不同。 如果myapplication使用kraft ABI，我们可以将应用程序和库映像进行比较，以查看实际使用了哪个ABI。

$ /usr/bin/objdump -T myapplication | grep kraft
08048330 DF *UND* 00000032 GLIBC_2.0 kraft
$ /usr/bin/objdump -T /lib/i686/libc.so.6 | egrep kraft
000bb160 g DF .text 00000032 GLIBC_2.0 kraft
000bb160 w DF .text 00000032 GLIBC_2.1 kraft

myapplication使用的适用于kraft的正确ABI应该为GLIBC_2.0，以便它将返回double值 。 库和操作系统可以演进，但是LSB刷新频率较低，可以为应用程序提供稳定的运行时环境。

术语

LSB的“一致性”要求在书面规范中阐明。 LSB“符合性”是开发人员对符合性的要求。 LSB“认证”是通过认证程序的合规证明（请参阅参考资料中的程序链接）。 “ LSB”是Linux Standard Base工作组所在的非营利组织Free Standards Group，Inc.的商标。

步骤3.使用LSB应用程序检查器进行测试

LSB应用程序检查器lsbappchk是LSB ABI合规性的主要测试。 下面是一个使用getpid() API的示例“ Hello World”应用程序。

清单1.“ Hello World”

#include <stdio.h>

   #include <unistd.h>



   main()

   {

       printf("hello world: %d\n", getpid());

   }

编译后，您可以检查helloworld.c以确定它是否符合LSB。 lsbappchk工具将应用程序使用的ABI符号与LSB书面规范定义的ABI符号进行比较。

$ lsbcc -o hw_good helloworld.c
$ lsbappchk hw_good
lsbappchk for LSB Specification 1.2
Checking binary hw_good

从lsbappchk输出中可以看到，它没有发现任何合规异常。 但是，如果我们稍微更改上面的示例以使用私有函数_getpid() ， _getpid()看到不同的结果。

$ lsbcc -o hw_bad helloworld.c
/tmp/cc5CITzio.o: In function 'main':
/tmp/cc5CITzio.o(.text_0xd): undefined reference to '_getpid'
collect2: ld returned 1 exit status

从lsbcc的上述标准错误（stderr）输出中，我们可以看到lsbcc不会使用不兼容的ABI来编译应用程序。 使用LSB lsbcc工具可帮助您避免创建不兼容的应用程序。

但是，如果我们使用本机编译器怎么办？

$ cc -o hw_bad helloworld.c

本机编译器允许应用程序使用系统的专用接口_getpid()进行编译，但是从LSB规范中我们知道这是错误的。 另外，我们知道我们绝不应该使用任何带有下划线前缀的接口。

$ lsbappchk hw_bad
lsbappchk for LSB Specification 1.2
Checking binary hw_bad
Incorrect program interpreter: /lib/ld-linux.so.2
Symbol _getpid used, but not part of LSB

从上面的lsbappchk的stderr输出中，我们可以看到该应用程序与错误的运行时加载程序相关联，并且正在使用不兼容的_getpid() ABI。 因此，即使您不使用lsbcc来捕获不合格问题，您仍然可以稍后使用lsbappchk来验证应用程序。 这种方法不是防弹的，但它是一个很好的指标。

步骤4.遵循LSB包装准则

使用LSB标头构建应用程序并与LSB存根库和运行时加载程序链接后，即可开始以LSB方式打包应用程序。 LSB指定您将应用程序打包为RPM v3格式的文件。 此外，您可能不会使用触发器，也不会依赖于预安装或预卸载脚本的执行顺序。 您还被限制为仅在这些脚本和应用程序中使用LSB指定的命令，因为不能保证其他命令会以预期的方式出现或表现出来。 LSB没有指定安装这些RPM打包的应用程序的工具。 您可以在基于RPM的系统上使用rpm工具，在Debian上使用Alien。

为避免在安装符合LSB的应用程序时发生名称空间冲突，属于基本操作系统或发行版的应用程序应安装在/ sbin /，/ bin /或/ usr /中。 系统管理员可以从源代码构建软件包并将其安装到/ usr / local /目录中。 但是，附加软件的第三方软件包必须安装在/ opt / <package> /中，其中<package>是描述软件包的名称。 这些/ opt /应用程序的关联文件可能位于/ var / opt / <package> /，/ etc / opt / <package> /和/ opt / share / <package> /中。 尽管LSB指定应在/ opt /中安装该应用程序，但最好在RPM spec文件中将其设置为可重定位的前缀。 如果存在缓解的情况，这将使安装程序覆盖该位置，并将文件放置在其他位置。

当然，守护程序的启动脚本必须放在/etc/rc.d/中。 应用程序的初始化脚本的名称必须唯一，并且只能使用字符[a-z0-9]。 为了避免名称空间的问题，它的名称必须与Linux名称和号码分配机构进行登记（LANANA;参见相关主题 ）。 如果脚本名称带有连字符，则最左边的字符串必须是在LANANA上注册的名称，或者可以是小写的完全限定域名。

除了避免文件系统层次结构中的名称空间冲突外，符合LSB的程序包还以“ lsb-”为前缀。 如果软件包名称仅包含一个连字符，则必须在LANANA上注册其名称。 如果程序包名称包含多个连字符，则第一组连字符之间的区域必须是在LANANA上注册的LSB提供程序名称，或者是您的小写全限定域名。 例如， lsb-java可能是Sun Microsystems向LANANA注册的名称，但可能还有另一个Java软件包名称lsb-unregistered.org-java ，但尚未注册。

步骤5.寻求LSB认证

开发LSB应用程序的最后一步是使其获得认证。 这个想法是，任何LSB应用程序都可以在任何LSB发行版上运行。 如今，至少有七个经过认证的运行时环境（请参阅参考资料中的列表）。 LSB正在努力建立大量的LSB应用程序。

您应该注意，只有“ LSB认证”应用程序-经过认证过程并签署了LSB商标许可协议的应用程序。 没有所谓的“符合LSB”的应用程序，因为它是经过认证的或未经认证的。 此外，经LSB认证的应用程序的所有者保证，他们的应用程序在两个LSB运行时环境（发行版）和LSB示例实现上通过所有者自己的功能验证测试（FVT）。 认证及其保修使LSB应用程序对消费者更具价值。

这是LSB认证期间作为应用程序开发人员的工作清单：

• 在LSB认证网站上注册自己
• 使用LSB提供的测试对应用程序进行自测试，然后上传结果
• 保证它通过您自己的FVT
• 完成符合性声明问卷
• 签署LSB商标许可协议

然后，上述信息将由证书颁发机构确认。 最后：

• 支付认证费用并签署LSB认证协议

结论

LSB的目标是使应用程序可以在任何Linux发行版上运行。 LSB实现此目的的方法是通过发行和应用认证，并提供符合性保证。 如果您的系统或应用程序执行不符合要求的操作，则客户可以要求您根据规范对其进行修复。 定义明确的ABI使得可以“收缩包装”应用程序并将其放在架子上，以在本地计算机商店出售。 产品包装盒侧面的“系统要求”列表应显示“ LSB v1.2”，而不是Linux发行版的特定版本。

当您可以将市场扩展到任何符合LSB的系统时，为什么将产品的潜在安装范围限制为仅几个系统？ LSB的副作用是较少的软件测试，同时允许其安装在较大的Linux系统上。

我要求您花一些时间下载LSB开发环境，重建您的应用程序，然后使用LSB应用程序检查器对其进行测试，以查看您的兼容性。 您可能会发现只需要进行一些小调整就可以符合要求，或者您可能需要重写使用私有系统接口的区域。 无论哪种情况，您都可以就应用程序的兼容性和原因做出明智的决定。

---

翻译自: https://www.ibm.com/developerworks/opensource/library/l-lsb/index.html

centos lsb