You should have a look at the Linux Standard Base. It's designed specifically to help people in your position. It defines an environment that 3rd party application developers can rely upon - so there's set version of libc and other libraries, and certain programs and directories live in known places. All of the main Linux distribution support LSB.
That said, you should still probably package the result specifically for each major distribution - just so that your customers can manage your app with their familiar package management tools.
Basically, there are two ways. You can chose both, if you wish.
The first way is the common way games and such do it. Make a lib/ subdirectory, use LD_LIBARY_PATH and include just about every shared library you need. That ensures a pain-free experience from your user, but does make the installer bigger and probably the memory footprint bigger as well. I would not even attempt to reuse preexisting libraries, as they would tend to disappear as upgrades are made to the system.
The second way is to provide distribution packages. These are generally not that hard to make, and will then integrate nicely with the distributions, and will furthermore seem a lot more welcoming to your customers. The 2 downsides are: You'll need to do this for each distribution (Debian, Ubuntu, SuSE, redhat is probably a good start), and you will need to maintain them: as time goes on, some libraries will no longer be available in a specific version, and thus the user will get dependency problems.
In your installer, check which libraries are installed and then download the binaries for those which aren't.
For additional comfort of your users, if there is no connection to the Internet, have the installer generate a key which you can enter on your website to receive a ZIP archive which you can then feed to the installer.
For utmost comfort, check which libraries are available on the target distro and ask the user to use the standard admin tool to install them. That way, you won't pollute the computer with different versions of the same library.
That said: It might be smarter to put your valuable code into a link library and then provide that as binary blob in a source package. This way, your code is as protected as it would be in a pure binary and users can compile the glue code on their favorite system without you having to worry about stuff.
I mean: How much worth is the part of your code which sets up the UI? How much will you lose when someone steals that?
发布评论
评论（3）
您应该查看 Linux 标准库。它是专门为帮助处于您职位的人而设计的。它定义了第 3 方应用程序开发人员可以依赖的环境 - 因此有 libc 和其他库的固定版本，并且某些程序和目录位于已知位置。所有主要的 Linux 发行版都支持 LSB。
也就是说，您仍然应该专门针对每个主要发行版打包结果 - 这样您的客户就可以使用他们熟悉的包管理工具来管理您的应用程序。
You should have a look at the Linux Standard Base. It's designed specifically to help people in your position. It defines an environment that 3rd party application developers can rely upon - so there's set version of libc and other libraries, and certain programs and directories live in known places. All of the main Linux distribution support LSB.
That said, you should still probably package the result specifically for each major distribution - just so that your customers can manage your app with their familiar package management tools.
基本上有两种方法。如果您愿意，您可以选择两者。
第一种方式是游戏等常见的方式。创建一个 lib/ 子目录，使用 LD_LIBARY_PATH 并包含您需要的几乎所有共享库。这确保了用户获得无痛体验，但确实使安装程序变得更大，并且可能还会占用更大的内存占用。我什至不会尝试重用预先存在的库，因为随着系统升级，它们往往会消失。
第二种方式是提供分发包。这些通常并不难制作，然后会与发行版很好地集成，而且看起来更受您的客户欢迎。两个缺点是：您需要为每个发行版执行此操作（Debian、Ubuntu、SuSE、redhat 可能是一个好的开始），并且您需要维护它们：随着时间的推移，某些库将不再可用在特定版本中，因此用户会遇到依赖问题。
Basically, there are two ways. You can chose both, if you wish.
The first way is the common way games and such do it. Make a lib/ subdirectory, use
LD_LIBARY_PATHand include just about every shared library you need. That ensures a pain-free experience from your user, but does make the installer bigger and probably the memory footprint bigger as well. I would not even attempt to reuse preexisting libraries, as they would tend to disappear as upgrades are made to the system.The second way is to provide distribution packages. These are generally not that hard to make, and will then integrate nicely with the distributions, and will furthermore seem a lot more welcoming to your customers. The 2 downsides are: You'll need to do this for each distribution (Debian, Ubuntu, SuSE, redhat is probably a good start), and you will need to maintain them: as time goes on, some libraries will no longer be available in a specific version, and thus the user will get dependency problems.
在安装程序中，检查已安装哪些库，然后下载未安装库的二进制文件。
为了让用户更加舒适，如果没有连接到 Internet，请让安装程序生成一个密钥，您可以在网站上输入该密钥以接收 ZIP 存档，然后将其提供给安装程序。
为了获得最大的舒适度，请检查目标发行版上有哪些库可用，并要求用户使用标准管理工具来安装它们。这样，您就不会因为同一库的不同版本而污染计算机。
也就是说：将有价值的代码放入链接库中，然后将其作为源代码包中的二进制 blob 提供，可能会更明智。这样，您的代码就可以像纯二进制文件一样受到保护，并且用户可以在他们喜欢的系统上编译粘合代码，而无需您担心其他事情。
我的意思是：您的用于设置 UI 的代码部分有多少价值？如果有人偷了你会损失多少？
In your installer, check which libraries are installed and then download the binaries for those which aren't.
For additional comfort of your users, if there is no connection to the Internet, have the installer generate a key which you can enter on your website to receive a ZIP archive which you can then feed to the installer.
For utmost comfort, check which libraries are available on the target distro and ask the user to use the standard admin tool to install them. That way, you won't pollute the computer with different versions of the same library.
That said: It might be smarter to put your valuable code into a link library and then provide that as binary blob in a source package. This way, your code is as protected as it would be in a pure binary and users can compile the glue code on their favorite system without you having to worry about stuff.
I mean: How much worth is the part of your code which sets up the UI? How much will you lose when someone steals that?